Salta al contenuto
Citiverse è uno spazio aperto a tutte le comunità. Se vuoi aprire un gruppo locale o una sezione per la tua organizzazione, puoi contattare gli amministratori: pagina dei contatti.

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_count is 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.

    Changelog

  • 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_count is 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.

    Changelog

    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

    https://w3id.org/fep/ae0c


Citiverse è un progetto che si basa su NodeBB ed è federato! | Categorie federate | Chat | 📱 Installa web app o APK | 🧡 Donazioni | Privacy Policy

Il server utilizzato è quello di Webdock, in Danimarca. Se volete provarlo potete ottenere il 20% di sconto con questo link e noi riceveremo un aiuto sotto forma di credito da usare proprio per mantenere Citiverse.