Abandoning this diff. We're going with the approach introduced in https://phab.comm.dev/D13819 where commbot is added as a ghost
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Wed, Oct 30
Abandoning with new approach in setting the viewer as a ghost
In D13802#386045, @ashoat wrote:You can't update the commit message with arc diff. Instead, you should edit the revision on Phabricator, and then run arc amend locally to update the commit text based on what's on Phabricator. (I think this last step also gets run automatically as part of arc land.)
You can't update the commit message with arc diff. Instead, you should edit the revision on Phabricator, and then run arc amend locally to update the commit text based on what's on Phabricator. (I think this last step also gets run automatically as part of arc land.)
Update commit message
Update commit message
Actually, would like to have @tomek opinion too
Tue, Oct 29
Abandoning. We're no longer planning to override permissions
address feedback
See feedback in D13812 – we wouldn't need to remove commbot if we never add them to the thread
Rebase and implement requested changes
Rebase and implement requested changes
Rebase
There’s a risk here that if a community root ends up in the thread store, but its keyserver isn’t returning it when queried here, then we could end up querying over and over. Can you make sure that we only trigger a query once for each ID? We have something similar in UserInfosHandler: https://github.com/CommE2E/comm/blob/603f6924736f20014f39c6b57dffe4e39c9ba7d4/lib/handlers/user-infos-handler.react.js#L43
rebase and review feedback
undo debounce, which didn't seem to work as expected
debounce fetch community infos
review feedback
var startTime = performance.now()
I would prefer a slightly different approach, where we could read Inbound messages and add them to the queue, there is no point in deffering this - but instead wait with actual processing, to achieve that we might need to modify useActionsQueue to be able to conditionally start processing, what do you think?
Makes sense, thanks for explaining!
In D13802#385659, @ashoat wrote:Question about the test plan:
After this patch there should be less of them
Did some of errors still appear? What's your theory for why that is?
In D13793#385651, @tomek wrote:This implementation has a performance consequence - in the original implementation, we were only stringifying when an alert was shown. Now we're stringifying the object even for users who will never see an alert. We could consider keeping the JSON.stringify inside showAlertToStaff, but I'm not sure if it is really that important.