Activity-Relay Server 2.5.0 RC2 pushed
-
Activity-Relay Server 2.5.0 RC 2 is now live at https://relay.argentwolf.org
Please help me out with connecting and testing! If you have any issues, please let me know! You can reach me at @alan, or open an issue on https://github.com/thystra/Activity-Relay
RC2 enhancements include:- Reliable delivery retries: Each relay fan-out target now receives one initial attempt plus five delayed retries.
- Bounded Fibonacci backoff: Retry delays occur at approximately 8, 13, 21, 34, and 55 seconds.
- Longer activity retention: Shared activity bodies remain in Redis for 15 minutes, covering the full retry window with additional margin.
- Correct terminal accounting:
remain_countis reduced only after successful delivery or final retry exhaustion—not after every failed attempt. - Protection against premature payload deletion: A temporary failure from one receiver can no longer delete the activity needed by its own retry or other pending receivers.
- Structured delivery diagnostics: Logs now include task UUID, activity storage ID, activity/object/actor identifiers, origin domain, receiver domain, attempt number, remaining retries, and body SHA-256.
- Delivery timing details: Each attempt records elapsed processing time and the scheduled time or delay for the next retry.
- Improved HTTP failure evidence: Logs capture HTTP status codes, classified error types, and bounded response text from receivers, including useful errors such as
424 Failed Dependency. - Safer diagnostic logging: Raw activity bodies, HTTP signatures, private keys, and unbounded remote responses are not written to logs.
- At-least-once recovery: A receiver that finishes processing after the relay times out may receive the same activity again during retry, allowing recovery from ambiguous timeout outcomes.
- Receiver-health tracking across retries: Successful and failed attempts update per-receiver delivery statistics and consecutive-failure state.
- Regression coverage: New tests verify retriable failure retention, successful later delivery, terminal cleanup, retry timing, metadata extraction, and bounded response handling.
- Operational observability: RC2 supports private health, readiness, and Prometheus metrics endpoints, now enabled locally in production on
127.0.0.1:9090. - Preserved upgrade state: Deployment validation confirmed that the relay actor identity, private key, configuration, website settings, and all Redis logical data remained intact during the RC1-to-RC2 upgrade.
#activitypub #friendica #mastodon #fediverse #nodebb #relay #relayserver #relayservers #relaytest
-
Activity-Relay Server 2.5.0 RC 2 is now live at https://relay.argentwolf.org
Please help me out with connecting and testing! If you have any issues, please let me know! You can reach me at @alan, or open an issue on https://github.com/thystra/Activity-Relay
RC2 enhancements include:- Reliable delivery retries: Each relay fan-out target now receives one initial attempt plus five delayed retries.
- Bounded Fibonacci backoff: Retry delays occur at approximately 8, 13, 21, 34, and 55 seconds.
- Longer activity retention: Shared activity bodies remain in Redis for 15 minutes, covering the full retry window with additional margin.
- Correct terminal accounting:
remain_countis reduced only after successful delivery or final retry exhaustion—not after every failed attempt. - Protection against premature payload deletion: A temporary failure from one receiver can no longer delete the activity needed by its own retry or other pending receivers.
- Structured delivery diagnostics: Logs now include task UUID, activity storage ID, activity/object/actor identifiers, origin domain, receiver domain, attempt number, remaining retries, and body SHA-256.
- Delivery timing details: Each attempt records elapsed processing time and the scheduled time or delay for the next retry.
- Improved HTTP failure evidence: Logs capture HTTP status codes, classified error types, and bounded response text from receivers, including useful errors such as
424 Failed Dependency. - Safer diagnostic logging: Raw activity bodies, HTTP signatures, private keys, and unbounded remote responses are not written to logs.
- At-least-once recovery: A receiver that finishes processing after the relay times out may receive the same activity again during retry, allowing recovery from ambiguous timeout outcomes.
- Receiver-health tracking across retries: Successful and failed attempts update per-receiver delivery statistics and consecutive-failure state.
- Regression coverage: New tests verify retriable failure retention, successful later delivery, terminal cleanup, retry timing, metadata extraction, and bounded response handling.
- Operational observability: RC2 supports private health, readiness, and Prometheus metrics endpoints, now enabled locally in production on
127.0.0.1:9090. - Preserved upgrade state: Deployment validation confirmed that the relay actor identity, private key, configuration, website settings, and all Redis logical data remained intact during the RC1-to-RC2 upgrade.
#activitypub #friendica #mastodon #fediverse #nodebb #relay #relayserver #relayservers #relaytest
Since you're using AI to code this it may be worth exploring what aspects of Activity-Relay differ from what is detailed in the retrospective FEP ae0c
Ciao! Sembra che tu sia interessato a questa conversazione, ma non hai ancora un account.
Stanco di dover scorrere gli stessi post a ogni visita? Quando registri un account, tornerai sempre esattamente dove eri rimasto e potrai scegliere di essere avvisato delle nuove risposte (tramite email o notifica push). Potrai anche salvare segnalibri e votare i post per mostrare il tuo apprezzamento agli altri membri della comunità.
Con il tuo contributo, questo post potrebbe essere ancora migliore 💗
Registrati Accedi
Citiverse è un progetto che si basa su NodeBB ed è federato! | Categorie federate | Chat | 📱 Installa web app o APK | 🧡 Donazioni | Privacy Policy