GeoLeaf Core API - v3.0.0
    Preparing search index...

    Type Alias QuarantineReason

    QuarantineReason:
        | "deletedOnServer"
        | "layerNoLongerWritable"
        | "rejectedByServer"
        | "notImplementedByServer"
        | "retryBudgetExhausted"

    Why an entry was set aside instead of replayed or dropped.

    Type Declaration

    • "deletedOnServer"

      The server deleted the entity while it was being edited locally.

    • "layerNoLongerWritable"

      The layer stopped being editable between capture and push.

    • "rejectedByServer"

      The push was refused by the server for a reason replay cannot fix.

      ⚠️ NARROWED at B-199 (09/08/2026), and the previous width had a measured cost. This member used to name EVERY non-409/non-404 failure, transient server outages included: pushOne had a single branch for the whole spectrum. Since this reason is excluded from REQUEUEABLE, a 503 during maintenance spent the replay budget and then left the capture unreplayable — its only remaining exit being destruction. It now covers 4xx refusals only, 404 and 501 excepted: malformed request, missing right, verb not allowed, unprocessable entity. A server outage is retryBudgetExhausted; an unimplemented verb is notImplementedByServer.

    • "notImplementedByServer"

      The server does not implement the verb — HTTP 501.

      🛑 ADDED at B-199, and the asymmetry it closes is the reason it exists. An unimplemented verb on the CLIENT side (the rest dialect, push-engine.ts) already fell through to retryBudgetExhausted and was therefore replayable; the same fact reported by the SERVER landed on rejectedByServer and was not. Same fact, opposite outcomes.

      It is set IMMEDIATELY — replaying a verb the server does not know only waits three times, the same argument as deletedOnServer — and it IS replayable: the lifting condition is the server being upgraded, which no local check can observe, so it is entrusted to the operator exactly like retryBudgetExhausted.

    • "retryBudgetExhausted"

      The replay budget ran out — the entry failed MAX_REPLAY_ATTEMPTS times without the server ever answering in a way replay could act on.

      ⚠️ AJOUTÉ à la tâche 4.11d (B-125), et il manquait pour une raison précise. Les trois motifs au-dessus nomment tous une CAUSE observée côté serveur ou côté couche. Un budget épuisé n'en est pas une : le serveur a pu ne jamais répondre. Réutiliser rejectedByServer pour un délai réseau aurait été un mensonge que le code lui-même détecte — push-engine distingue déjà networkError de rejectedByServer.

      Il porte aussi les pannes serveur transitoires depuis B-199 — 500, 502, 503, 504, 408, 429. Sa phrase les couvrait déjà (« without the server ever answering in a way replay could act on ») : c'est la classification en amont qui ne les lui envoyait pas.