Respect 429 (Retry After) response

[mindplay-dk]

If Sentry returns a 429 (Retry After) HTTP status, the client is over the usage limit - the client should respect that, back off and wait for a while.

This isn't completely trivial to implement, since PHP scripts are stateless - we'll need to record the back-off period in a flat file somewhere maybe.

Or this may be part of a somewhat larger solution that also enables us to buffer to disk if the Sentry back-end fails to respond.

Needs design proposal/spec before implementation.

[M1ke]

I've just emailed Sentry about whether they know of clients that buffer to disk and some Googling led me here. The idea of saving to disk is an interesting one; I guess the platform already has enough data to do this, because it knows what data it would send. The only unknown is how it goes about sending it. I'd suggest a simple agent-process that just needs to know the directory where messages are saved - all relevant data could be contained in the messages. This way the agent could be run as a cron, by supervisor or some other tool, within an async PHP env or manually for low traffic sites that do a daily sweep.

I notice this is nearly 4 years old though - is there appetite for using this still?

[mindplay-dk]

I don't work on this project anymore, so my opinion won't count for much - but one thing to consider is, the concept of an agent process isn't native to the PHP platform. So every framework/project will need a custom integration/solution.

If you provide some sort of stateful (SQLite, flat file, Cache, etc.) service for this, people will likely set this up wrong - it's likely they won't know if their cronjob or integration is currently working or not.

I'm not sure what to suggest, but it's not my responsibility anymore, so 😅