Skip to content
DarkPrint
Aautogenbounded-retry2.0.0

Bounded Retry

Get card

Clone

npx -y darkprint clone bounded-retry@2.0.0

There is no repository and no history behind a card. Download hands you the document as it stands, and Clone fetches the same document by name.

↓ 2 downloads

Restore the most recent valid checkpoint and re-fire the failed stage from there, backing off between attempts until the cap is spent, then emit the last error.

used in 2 blueprints

Specification

102 words · handed to the agent

You may be handed a failure signal, a checkpoint snapshot, or both; either one on its own is enough to act on. With a checkpoint in hand, restore state from it as far as the last valid stage and re-fire that stage from the restored state; with only a failure signal, re-issue the attempt exactly as it stood. Wait 800 ms before the first retry and double the wait on every retry after it, emitting each re-issued attempt on attempt with its attempt number. Give up after three retries: emit the error from the final attempt on last_error and restore nothing further.

Interfaces

2 in · 2 out

Inputs

2
Inputs declared by this node card
NameData typeRequiredDescription
failurestatus optionalThe failure signal from the step being wrapped, when the caller has one to hand.
checkpointjson optionalThe snapshot to resume from; without it the node simply re-fires the last attempt.

Outputs

2
Outputs declared by this node card
NameData typeDescription
attemptjsonThe re-issued attempt, numbered so the receiver can tell a retry from a first run.
last_errorstatusThe final error, surfaced once the cap is spent instead of being swallowed.

Dependencies

1

The upstream nodes this card expects to receive from. Whenever a blueprint pins this card, each name is checked against a real edge in that graph. A name without a link is not a published card; it refers to a node inside some graph.

Card values

16 declared

Who the node is. The id is the key the DOT pins.

id
bounded-retry
name
Bounded Retry
type
tool
phases
Debugging
Behaviourcard spec →

What it does, and the prose the agent is handed when the graph runs.

action27 words
Restore the most recent valid checkpoint and re-fire the failed stage from there, backing off between attempts until the cap is spent, then emit the last error.
spec102 words
You may be handed a failure signal, a checkpoint snapshot, or both; either one on its own is enough to act on. With a checkpoint in hand, restore state from it as far as the last valid stage and re-fire that stage from the restored state; with only a failure signal, re-issue the attempt exactly as it stood. Wait 800 ms before the first retry and double the wait on every retry after it, emitting each re-issued attempt on attempt with its attempt number. Give up after three retries: emit the error from the final attempt on last_error and restore nothing further.in full above
model
whatever the graph supplies
agent
Resume controller
skill
skills/bounded-retry.md
tools
none
mcp
none
params
backoff_ms: 800, max_retries: 3, restore_scope: last-valid-stage, backoff_multiplier: 2
Interfacescard spec →

What arrives, what leaves, which nodes it expects to hear from, and what may not.

inputs
failure : status, checkpoint : json
outputs
attempt : json, last_error : status
dependencies
episodic-memory
cannot
no type is refused
will_not
retry past the declared cap, restore past the last valid stage
Evaluation metadatacard spec →

The keys the static analysis reads. Nothing here instructs the agent.

risk_markers
none
notes105 words
Both inputs are optional because either one is enough to act on: a failure signal alone re-fires the attempt, a checkpoint alone restores and continues. max_retries is still the declared bound the security analyzer reads for the cycle this node closes. The version is 2.0.0 because restore past the last valid stage is an undertaking 1.0.0 never gave. It sits under will_not, which inferBump prices as minor either way round, since the resolver never reads it and no graph changes its answer. The major is the author's: a node that has started refusing to restore past a stage boundary behaves differently on the same wiring.
Service fieldscard spec →

The card's own version, and who wrote it.

version
2.0.0
author
autogen
provenance
not stated

Definitions for every card field

Version history

2 versions published
  1. bounded-retry@2.0.0currentsha256:9187c75955624c7688b5f6cac3637669ff3bec13bd6695af57f39b0746e72356

    pinned byCheckpoint & Resume Runnerautogen/checkpoint-resume-runner

    major1.0.0 → 2.0.0moving a pin to this version may break a blueprint that resolved against the old one
    • promise swallow the error from the final attempt was withdrawn (nothing checks this automatically)
    • optional input checkpoint was added
    • promise restore past the last valid stage was added
    • dependency episodic-memory was added
    • parameter restore_scope was added
    • spec changed, the instruction handed to the agent is different
    • input failure is no longer required
    • input failure description changed
    • dependency acceptance-verifier was removed
    • agent changed: "Retry controller" → "Resume controller"
    • action wording changed
    • notes changed
  2. bounded-retry@1.0.0sha256:5ec4cba27984adecbe82116dc1a9726fec117aaf9053c6938f00f5413773e330

    pinned byAdversarial Consensus Lineautogen/adversarial-consensus-line

A digest is a fingerprint (SHA-256) of the card's content, computed without the author and provenance fields. The same card from two people gets the same digest; any edit gets a new one.

Community notes (0)

No notes yet.

Nobody has posted about this node card yet.

Sign in to post a note.