You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently the forward-port decisions are only logged to, well, the log. Which is very opaque and hard to access (even for me).
It might be a good idea to log it to the source PRs or the chatter (possibly adding a batch chatter for that? would allow tracking batch shit too). One probable limitation in that case is that "wrong state" keeps running possibly forever, so would have to be modified / handled specially in order not to make this a pain in the ass...
Alternatively there could be a special signal to handle this and avoid even trying to schedule followups for PRs or batches which can't have changed (so probably gate _validate to first check the pr / batch state).
The text was updated successfully, but these errors were encountered:
After thinking more about this, I think it would make sense for forwardport batches to be tracked and have their state computed through dependencies through the PR, rather than check the properties we want on every cron run. The cron should only be there to perform the work when the batch is in the right state.
It would also allow surfacing batches stuck in an inconsistent state more easily, though I think currently this just leads to the batch being dropped for the most part? Either way, this ought allow for an easier time posting the final decision / result to the source of the batch too.
Currently the forward-port decisions are only logged to, well, the log. Which is very opaque and hard to access (even for me).
It might be a good idea to log it to the source PRs or the chatter (possibly adding a batch chatter for that? would allow tracking batch shit too). One probable limitation in that case is that "wrong state" keeps running possibly forever, so would have to be modified / handled specially in order not to make this a pain in the ass...
Alternatively there could be a special signal to handle this and avoid even trying to schedule followups for PRs or batches which can't have changed (so probably gate
_validate
to first check the pr / batch state).The text was updated successfully, but these errors were encountered: