Release Notes

v2.36.0

Release date: February 27, 2026

New features

Event Retry Endpoints

New endpoints for retrying failed event deliveries have been added for both effects and bridges:

These endpoints require the retry-event access action.

When to Use

Use this feature when:

  • Event deliveries have failed and exhausted all retry attempts
  • The target service (webhook endpoint or bridge) was temporarily unavailable or experiencing issues
  • You have fixed issues on the target service and want to resume event deliveries immediately
  • You need to reprocess events from a specific time window

How It Works

When you retry events, the ledger will:

  1. Cancel all scheduled delivery jobs that are in a failed or pending state
  2. Reschedule them with no delay for immediate processing
  3. Resume event deliveries to the configured endpoint

You can specify an maxAge parameter (in minutes) to limit retries to events whose last delivery attempt was created within the past N minutes (default: 60, max: 48 hours enforced server-side). Note that the last delivery attempt can be, e.g. 50 minutes ago, but for an event that was generated further back in time than that. Set maxAge to 0 to retry all events regardless of age.

API Usage

REST API:

POST /v2/effects/{effect-handle}/events/retry
Content-Type: application/json

{
  "data": {
    "maxAge": 60
  },
  "hash": "...",
  "meta": {...}
}

Node.js SDK:

const { effect } = await sdk.effect
  .with('my-effect-handle')
  .events.retry({
    maxAge: 60
  })
  .hash()
  .sign([{ keyPair }])
  .send()

CLI:

minka effect events retry my-effect-handle

The CLI will prompt you for the offset value (default: 60 minutes) and guide you through signer selection and confirmation.

Response

The endpoint returns a 202 Accepted status, indicating that the retry request has been accepted and will be processed asynchronously.

Backward Compatibility

The legacy POST /effects/:id/activate and POST /bridges/:id/activate endpoints are kept for backward compatibility. They follow the same behaviour but require the activate access action instead of retry-event.

Improvements

  • [docs] Added docs on how to verify hash and signatures from ledger
  • [ledger] Added a limit to the amount of proofs any record can have in its meta field. Safeguards the system against memory allocation issues. Currently defaults to 100 proofs.