With the new sandbox setup, we no longer have direct access to the error logs on production, which will make it difficult to learn about and reproduce errors in order to fix them.
I have a couple ideas about potential solutions, but I’d like to know if Systems has any thoughts or preferences.
1) Pipe errors into SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/., the same way that w.org does. This would require setting up object caching (to rate limit the APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. hits, per Slack’s ToS). IIRC, @kovshenin looked into this a few years ago, and determined that there was a non-trivial amount of code that would need to be refactored in order to make it work. Konstantin, do you remember the details there?
2) Setup a cron job on production to parse the raw error log on disk, reduce it to the relevant/limited entries, and push those to Slack.
3) Setup a cron job on production to copy the raw error logs from production to sandboxes every ~60 seconds. They’d need a different name than the sandbox error logs, so that we could have both.
@coreymckrill and I could write any scripts that are necessary, etc.
Do you see any problems with any of those, or have any other ideas or suggestions?