Migration map.

task_status — inspect saved work

resource-specific discovery has narrower enums and different default requirements.

Read the saved state of an existing workflow before deciding whether to resume it. This does not execute remaining business steps. Use the workflow's get tool for current business data and task_resume only when continuing the saved operation is intended.

Input and identity

{"taskId":"example-profile-001","taskType":"account-profile"}

Replace the illustrative ID with an existing task's ID. A channel ID/code, screen ID, and task ID are different identifiers. Neither field accepts null. Use the same runtime state storage and connection that created the task; the tool accepts no replacement target or account. A new dry run can return a request/task identifier without persisting a job, so status can legitimately return TASK_NOT_FOUND.

Account schemas expose seven types; selected-channel schemas expose 26 and require taskType. Local stdio exposes all 34, including local-only domain-favicon. The new segment type is channel-only. Descriptions render the allowed names and scope/default rules. An unknown or cross-resource type is not authorization to inspect another store; use the current scope table.

Inputs

Result

Successful retrieval returns the corresponding workflow result and saved progress. Older workflows use code:TASK_STATUS; newer ones may return their own COMPLETE/PENDING code. There is no universal status payload. Additional fields depend on the workflow:

A pending wrapper can contain an error or unknown outcome in lastResult. It does not mean a background worker is still running. A done phase does not prove that external DNS, visitor rendering, live permissions, or another requested workflow is complete.

Reads, effects, and access checks

The operation reads private job records and checks their connection/identity bindings. It executes no remaining business write or workflow step. Connection and authorization handling follows the selected workflow; this is not a blanket guarantee of zero credential-related activity. It is not guaranteed to be network-free: member-moderation and manager status recheck channel context/permissions; profile/contact status rereads self-account identity. These guards do not turn the stored business result into fresh verification. State initialization or task locking can touch local storage.

Channel creation status reports phases prepared, creating, created, done, or failed. creating can mean an uncertain creation response; created means an identifier was saved and later steps may remain. Other workflows use their own phases; consult their saved result rather than applying creation's state names to all tasks.

Failure and next action

• TASK_NOT_FOUND: check the exact ID/type, environment, state storage, and whether a dry run ever created a job. Do not create a new request solely to work around an uncertain earlier write.
• Connection, owner, account, or target mismatch: keep the original binding; another account must not inspect or adopt the task.
• STATE_PERMISSIONS or TASK_LOCKED: have the operator inspect storage or an existing operation. Do not delete state or locks blindly.
• Authentication or access failure: restore the correct connection and permissions before retrying.

Error payloads can omit task metadata depending on where validation failed. Inspect common results and recovery rules. For completed jobs, use a fresh workflow read; for incomplete jobs, preserve the original input and inspect whether resume may still mutate data.

Implementation: the task dispatcher in src/server.ts, src/state.ts, and each workflow's status method.

Older saved member-ban reasons

See the current reason-length and recovery rule. Status can report dispatchBlocked:INVALID_BAN_REASON for an unsent old ban. Resume does not rewrite it or send that invalid reason. Already-sent tasks still reconcile, and completed records remain historical.

Older saved SEO text

The current SEO text contract preserves old input records. Status marks an overlong prepared/uploaded plan with dispatchBlocked:INVALID_SEO_TEXT; resume leaves its journal and object intact without saving. Already-sent stages retain their existing uncertainty/reconciliation rules and are never repeated.

Campaign creation status

Copy its taskId and original selected context. Status reads saved progress; resume only observes. Prepared work can dispatch only through the identical create call after fresh checks. Sent creation never repeats, and absent receipt identity is not recovered by title or list changes. A receipt binds both campaign and initial-benefit identities; an equivalent replacement benefit cannot satisfy recovery. Completed replay is historical.

Article catalog and image-card recovery

Copy its returned type instead of content-settings. Status is historical; resume or identical sent apply only observes the exact expected membership set and preserved catalog/price/target/retained-membership records. An unresolved durable catalog guard prevents a new request from bypassing the original task. Runtime deployment and actual recovery/access/restoration remain unverified; no successful live task is implied by this namespace.

Pricing, content-link and membership changes share one guard. Unresolved work of any kind blocks fresh requests of the other kinds; sent pricing retries/resume only read back and never repeat save/discard. Changed price identity, unrelated fields, catalog flags, currency or branding remain unverified. Historical completion does not confirm current price, original-console parity, visitor access or restoration.

All four catalog action kinds block each other while uncertain. Sent detail retries/resume only observe the original catalog and linked references, never repeat PUT; unexplained catalog metadata/timestamp drift remains unverified. A historical result cannot establish current activation or restored visitor access.

Status reports sent, created or done (the stored verified phase) and the historical result without a write or fresh readback. Sent does not prove dispatch; created requires a durably stored receipt identity. An unresolved creation blocks fresh catalog writes across the exact installed instance. Unknown identity is not inferred from title/list differences.

Status reports stored sent/done progress and lastResult without a new deletion or fresh absence check. Only a verified saved result contains deletedCatalogId; planned/uncertain results identify catalogDeletionTarget. The surviving list is a parent destination, and historical results cannot establish current absence, preserved posts, physical price cleanup, purchase rights or restoration.

Status/resume observe all creation phases and cannot issue credentials, upload or POST a card. Only identical apply can continue a prepared or durably image-ready stage after revalidation with the original bytes/context/storage/snapshot. Uncertain image-sent and create-sent effects never replay. An image acknowledgement is not creation; a matching created card requires the unique issued-image identity and preserved prior state. Fresh observation requires revision, acknowledged image, matching sent phase and current state; a fresh mismatch remains pending with a parent link, while missing fields, image-only checkpoints and historical results expose no product link. Source connection does not prove actual upload, console state or restoration.

Shop image and creation tasks

Shared status/resume never issue credentials, PUT bytes or POST a product; prepared work needs the identical original input. Issuing/uploading image uncertainty never repeats. A sent creation requires its durably saved product identity to reconcile and cannot adopt a resource by title or a new requestId. Image references also retain credential-version/storage binding. Completed results are historical with no fresh success link; use the relevant reader for current state.

Later existing-method recovery options

Buyer input-field creation retains commerce-product-settings but needs the exact new field identity from the REVISE response; sent uncertainty never adopts a title or resends. Older settings journals keep their prior requirements. Card image replacement retains media-live with image-sent/image-ready/update-sent checkpoints; status/resume only observe and cannot upload or PUT the card. Article category selection retains content-post; a sent request only rechecks saved selection and fresh eligibility.

Shorts conversion-link receipt identity

Creation saves the exact string distinctId as receiptIdentity alongside its numeric post receipt before fresh observation. Missing/lost identity stays pending even if a link now exists; status/resume cannot adopt it or resend a sent write. Prepared recovery is observation-only. Ordinary numeric resource journals remain compatible. The dedicated link revision and unchanged post/link fields govern readback; Only validated fresh sent/done observations can resolve the current screen; a fresh mismatch remains pending, and prepared, unobserved, historical or foreign results have no link. A link does not repair missing receiptIdentity or prove actual restoration.

Messenger room creation status

Status checks the saved context and reports historical prepared/catalog-sent/catalog-confirmed/room-sent/done progress. It sends no business write and does not freshly verify a completed room. Unknown catalog/room identity and orphan catalogs remain unresolved. See the writer for the narrow default-image scope and separate MES/Hosting readiness limits.

Article GENERAL label lifecycle recovery

It is separate from content-taxonomy category jobs and content-post selection jobs; copy the returned type. Status is historical. Resume or identical sent apply reads the complete inventory without repeating a POST/PATCH/DELETE, and does not require the writer hook to remain present. A missing creation receipt never permits name adoption. Completed results are historical; context/credential/instance changes block recovery. Deletion does not restore old IDs/associations. Shared SDK fixtures exercise direct/compact channel routing and observation-only sent recovery, including missing-writer rename/delete recovery.

Existing seated ticket policy tasks

The historical taskType values commerce-legacy-ticket-policy and commerce-legacy-ticket-label are channel-scoped compatibility notices only, not executable workflows. Both status and resume return action_required / COMMERCE_PAPP_RETIRED with supportEnded:true, writesPerformed:false, writesPerformedThisCall:false, journalAccessed:false and verification.confirmed/currentStateVerified:false. There is no current console link. Account scope rejects these identifiers.

These notices do not open a journal or determine whether the task exists, succeeded or failed. Existing mixed Commerce journal handlers also stop recorded E00002 targets before ordinary plan validation or host effects. Preserve prepared, sent, completed and uncertain records; no retry, observation of business state, migration, deletion or automatic restoration is provided. Do not repeat the removed apply method, change request IDs or replace the app code to continue an old effect. Contact the operator for uncertain historical outcomes.

E00003 ticket pricing status

Use the existing taskType commerce-ticket-pricing and original taskId for ticket_pricing_apply. Status reports saved prepared/sent/done progress after context and authorization checks; it sends no business write and does not reread the current event policy. Historical results have verification.confirmed:false and no current verified console link. Use ticket_pricing_get for current business data.

A sent link requires its durably returned new price identity. Missing identity, partial unlinking and uncertain persistence remain unresolved; status cannot infer a receipt or restore a link. Keep lastCode, saveAcknowledged, journalPersistence and the original input. writesPerformed describes the stored task, not a new status effect. A plain getter or new dry run creates no task.

E00003 cancellation settings status

Use taskType commerce-ticket-refund-settings with the original taskId from ticket_refund_settings_apply. This is separate from commerce-ticket-pricing and retired E00002 tasks. Status reports saved prepared/sent/done progress under current context/authorization without a new business write or fresh policy read. Historical results have current verification false, writesPerformedThisCall:false and no current verified console link. A getter or new dry run creates no journal.

Inspect lastCode, saveAcknowledged and journalPersistence; writesPerformed belongs to the saved task. Partial saves and uncertain persistence remain unresolved. Use fresh settings reads for current data and observation-only recovery for sent work. Neither status nor a stored completion proves actual customer cancellation/refund effects or restoration.

<a id="ticket-policy-metadata-candidate-status"></a>

Ticket policy metadata status

Metadata name/management-label changes use the existing taskType commerce-ticket-pricing. Status reports saved prepared/sent/done metadata history under current context checks, with no fresh event/catalog read or business write. Historical results have current verification false and no current home link. Metadata edits need no created-price receipt; do not apply tierLink identity rules or rename a tier task to adopt it. Use a fresh exact metadata read for current names/links, and preserve the original task/request for uncertainty.

E00003 discount settings status

For nondelete settings use the existing taskType commerce-ticket-discount-settings and original taskId from ticket_discount_settings_apply. Status reports stored prepared/sent/done progress under current context and authorization; it sends no business write or fresh policy/catalog read. Historical results have current verification false, writesPerformedThisCall:false and no current verified link. A getter or new dry run creates no job. Use ticket_discount_settings_get for current values.

Keep lastCode, saveAcknowledged, journalPersistence and the original input. writesPerformed describes the task, not this status call. A tierLink needs its durable exact new override ID; status cannot infer it from a label or list difference. Other operations edit known identities, but saved history alone does not verify their current state. Partial saves or uncertain persistence remain unresolved.

E00003 ticket operation status

Use taskType commerce-ticket-operation and the original taskId from ticket_operation_apply. Status validates the stored prepared/sent/done journal and current authorization without a fresh schedule/sheet read or business write. Historical results have current verification false, writesPerformedThisCall:false and no current verified console link. A getter/new dry run creates no journal; writesPerformed describes the stored task, not a status action.

Preserve the original input, lastCode, saveAcknowledged and journalPersistence. Partial bulk changes, buyer races, mismatched slots and unconfirmed deletion remain unresolved by history alone. A missing schedule/404 does not prove deletion; an old completed result does not prove current state. Use current preparation for an intended operation and observation recovery for uncertainty. No receipt inference, replay, restoration or retired E00002 adoption is provided.

E00003 discount policy deletion status

Use that exact returned type and original taskId; do not substitute commerce-ticket-discount-settings or a public lifecycle method. Apply and recovery share one canonical deletion instance/store. Status validates saved prepared/sent/done history and current authorization, without a fresh active-inventory read or write. Historical results have current verification false, writesPerformedThisCall:false and no current verified link.

Selected policy absence in stored history is not current verification. Keep the original selection, confirmation, revision, requestId, lastCode and journal state for deletion recovery. The default cannot be deleted, and missing/partial inventories cannot prove completion.

Its history does not reread current override maps; use the exact price getter for current preparation. Earlier seven-option tasks retain their identities and journals.

Original article product tasks

Use the original taskId, not content-settings or a newly invented product task type. Status checks the saved target/current authorization and returns historical sent, created or done (stored verified) progress with lastResult. It does not send a product write or reread current product values; historical results have current verification false and no fresh verified link.

Sent records precede dispatch and do not prove an effect. Created requires a durably saved returned product identity. A missing identity cannot be inferred from a name or inventory difference, and an unresolved product write blocks fresh product creation/editing across that exact installed app. Product/catalog inputs cannot reuse each other's saved request IDs. Use observation-only recovery for the original task. Actual save, original-console agreement, visitor entitlement and restoration remain unverified.

E00003 schedule tasks

Single schedule create/edit uses commerce-ticket-schedule. Status reports stored prepared/sent/done progress, acknowledgement and historical completion under current context. It performs no business write or fresh schedule readback. A sent phase is not an effect receipt; created identity must be durably saved before recovery can observe it. The bounded list getter creates no task and provides no mutation revision.

Historical confirmation is false and no fresh link is supplied. Keep the original request and receipt; do not adopt an identity by matching title, switch request IDs or rewrite a journal. Current-state inspection needs the matching getter.

Discount settings status

Use taskType discount-settings and the original taskId from discount_settings_apply. Hosted discovery and the workflow enforce the exact selected-channel resource; account or foreign-channel access cannot inspect or recover this task. Current connection/operator/permissions and saved-record integrity are checked before returning progress.

Status sends no business write and does not reread the offer profile. It returns historical prepared/sent/done progress, storedCompletion, noop, writeAcknowledged, lastResult when present, and verification.confirmed:false. Historical writesPerformed describes the earlier task outcome, not a write by this status call; it can be null for an unacknowledged sent attempt. There is no current configurationRevision or verified console link. Use discounts_get for current values.

A fresh dry run persists no task, so TASK_NOT_FOUND can be expected. Real no-ops persist a done task without a write. Do not replace a request ID or alter a journal after uncertainty. The existing discount handoff still creates no task.

Schedule policy status

For operation.kind:policies through ticket_schedule_apply, use taskType commerce-ticket-schedule-policies and its original taskId. This canonical policy store is separate from commerce-ticket-schedule create/edit and commerce-ticket-operation seat actions; old journals retain their identities.

Status validates saved input, selection, context and prepared/sent/done progress under current selected-channel authorization. It sends no business write or fresh schedule/bulk-status read. Historical completion has current confirmation false, writesPerformedThisCall:false and no current verified link. Stored writesPerformed/saveAcknowledged describe that attempt and are not proof of a new effect. A fresh dry run creates no task; a real no-op creates a done task. Read the exact policy operation with ticket_schedules_get for current state. Global DONE or no REQUESTED rows never substitutes for verified schedule configuration.

Original article conversion tasks

Status checks the saved target and current context, then returns historical sent, created or done (stored verified) progress with lastResult. It makes no business write or fresh link/post readback. A sent record precedes dispatch and is not proof that an effect occurred; created requires a durably stored initialization identity.

The dedicated string distinctId is separate from numeric postId and channel-wide conversion IDs. Missing identity cannot be adopted from current state. Preserve the original task and input; uncertainty blocks fresh conversion and ordinary post writes on that article. Use readback-only recovery for the original task. Historical completion and navigation do not prove a current saved link, console/visitor agreement or restoration.

Discount creation status

Existing edits continue to use discount-settings. Status validates the saved draft, revision, receipt/progress and exact selected-channel context, then returns historical prepared, sent or done progress without a business write or fresh offer/inventory read. A sent marker is not proof of dispatch; writesPerformed and storedCompletion describe saved progress, with current verification.confirmed:false.

A new dcid/cotid and numeric identity must come from a durably saved authoritative receipt, never a code/name/list difference or supplied ID. Unknown identity remains unresolved, and historical results have no current configurationRevision or verified console destination. Keep the original request and use discount-create recovery. Account/foreign-channel access or changed connection/operator/permissions cannot recover another task; credential refresh is tolerated only after prepared.

Original article address tasks

Status checks the saved identity/current context and returns historical prepared, sent or done (stored verified) progress without a business write or fresh post/slug read. Creation identity and any valid slug receipt are persisted while the ordinary task remains sent; this option adds no created phase or task type. A sent record is not proof of an effect.

A valid durable post ID with a missing/malformed slug receipt permits inspection but not a verified address. A missing post identity cannot be inferred from similar content. Preserve the original input and use the matching recovery rules.

Multiple-date schedule status

The canonical root store is separate from commerce-ticket-schedule single create/edit and commerce-ticket-schedule-policies. The shared host injects the same batch instance into the existing get/apply workflow and task dispatch.

Status validates saved flat input, fingerprint, context, before snapshot, request digest, complete receipts and prepared/sent/done progress under current exact channel/installation authority. It performs no business write or fresh schedule readback. Existing flat draft/confirmation journals retain their identities without an operation-wrapper migration. Do not edit saved records or substitute another task type.

Results are historical, with writesPerformedThisCall:false, verification.confirmed:false and storedCompletion reflecting prior completion. Stored writesPerformed is false for prepared, true after acknowledgement and null for sent without acknowledgement; none proves a new write or complete creation. Done records include ordered exact occurrences, but no single batch scheduleId or current edit revision. Pending results may have no authoritative complete receipt set even if saveAcknowledged is true.

A fresh preparation/dry run creates no task. Preserve the original task after any uncertain sent result and use batch recovery; do not infer identities from a list, title or partial set. Historical results have no fresh verified console link.

Original article selection status candidate

Current source connection: The shared port now forwards bulk deletion through the existing guarded content transport.

Historical candidate boundary (next paragraph only; the heading and anchor remain stable):

Status checks saved identity and current exact context, then returns historical TASK_STATUS with lastResult and prepared/sent/done progress (stored verified is exposed as done). It makes no fresh target read or write. lastResult retains timestamped observations, with observationHistorical:true/currentSnapshot:false. Saved requestAttempted/writeRequestsAttempted describes attempt boundaries, not proven dispatch or completion.

Fresh dry runs create no task. Preserve the original input and use selection recovery for nonterminal rows, or a fresh selection read for current state. Completed/known-failed observations are not replaced on resume.

Selected schedule metadata status

The existing tools, guarded transport, canonical task recovery and parent navigation are connected in source.

For editMany, use taskType:commerce-ticket-schedule-edit-many and its original taskId. Single edit retains commerce-ticket-schedule, sharing the edit-many store's schedule-edit-guard. Status validates immutable input/context/plan/observations and returns historical prepared/sent/done state; it makes no fresh schedule reads or business writes and never releases claims.

selection retains hallId, eventId and every original scheduleId in order. Target state, execution and requested/preserved checks remain distinct. observationScope:stored_resolution is prior durable evidence, even within a later recovery result; current_attempt identifies an unresolved observation attempt. A done task can combine resolutions from different attempts and has no atomicity/causality guarantee. Historical verification.confirmed and currentStateVerified are false; the shared host supplies no current result link for historical status.

A fresh dry run creates no journal. Status does not show that a prepared-looking task with an existing claim is safe to resend, or that an old unregistered task has no outstanding effect. Use original recovery, preserving the same task and storage namespace. Guard absence before upgrade, another OAuth grant and unguarded commerce/console paths are not proof of global safety.

Original article assignee status

The existing tools and guarded transport are connected in source.

article_assignee uses the existing taskType:content-post and original taskId. Status checks saved task identity, selected channel and current context, then returns historical TASK_STATUS with lastResult and prepared/sent/done/rejected phase (verified is exposed as done). It performs no fresh article/assignee read or mutation and does not resolve pending markers.

lastResult may contain requestedAssignee, requestAttempted, transportCode and the original snapshotHistorical:true values. The attempted flag records the durable boundary, not proof that a remote request completed. The status envelope is historical:true with writesPerformed:false and no current result link. Any verification inside lastResult describes saved evidence, not a fresh observation; terminal apply/resume replays explicitly set current verification false. Read the dedicated getter for current assignment/candidates; use original recovery for unresolved work.

A fresh dry run creates no task. A no-op real apply can create a verified task with no attempted mutation. Old terminal records do not verify current eligibility, notifications, console display or restoration.

Course comment status

Registration, guarded transport, task routing and exact navigation are connected in source.

Course comment changes use taskType:media-course-comment and the original taskId. This workflow's status rechecks the selected context. Prepared work returns MEDIA_RESOURCE_PREPARED without dispatching; sent and done work reads the original parent and bounded comment inventory to compare the requested state and preservation. Unlike a stored historical status envelope, these follow-ups can issue GET requests. They never send a business mutation.

A match returns MEDIA_RESOURCE_OBSERVED/currentStateMatches:true with writesPerformedThisCall:false. A mismatch remains MEDIA_RESOURCE_UNCONFIRMED; a previously done phase alone is not current proof. Creation needs its saved authoritative receipt identity; deletion can observe its known original comment's absence even after an empty204 acknowledgement was rejected. No new ID is inferred by text/list changes. Notification delivery, causality and restoration remain unverified.

Old sent journals keep observation-only compatibility with the earlier text-length validator. Prepared over-limit text cannot be sent by status/resume. Read course comment recovery before continuing. A new requestId is not safe recovery, and no cross-task target lock is promised. Only a fresh, matching result receives the validated class/session destination; page/filter controls must be selected again in the screen.

Selected schedule publication status

The existing get/apply methods, transport, canonical task guard and publication-aware navigation are connected in source.

Publication reuses taskType:commerce-ticket-schedule-edit-many and the original taskId. Status validates saved immutable operation/selection/context/observations and returns historical prepared/sent/done progress. It does not read fresh schedules, dispatch STATUS or release claims. operationKind:publication distinguishes this operation from metadata editMany; the selection retains every original ordered ID and per-target before/requested/observed comparisons.

Stored resolutions may come from different attempts. Historical confirmation/currentStateVerified are false and no current successful link is provided; phase done does not prove present visitor visibility. Fresh get/dryRun and a prior completed no-op are neither new admission nor resolution of pending work. Use original recovery, preserving rollout HOLD and the same namespace.

Original article notification status

This connects the existing settings methods and canonical recovery in source.

Manager-comment notification preferences use existing taskType:content-settings and the original taskId. Status verifies saved identity, exact channel/installation and current authorization, then returns historical TASK_STATUS with lastResult and prepared/sent/done/rejected phase; stored verified is exposed as done. It performs no notification configuration read, PUT or pending-work resolution.

lastResult may contain snapshotHistorical, requestAttempted, requestedActive, transition or a saved inspection destination. These fields describe recorded evidence. The status envelope remains historical:true with writesPerformed:false; nested readback evidence is not a fresh verification and does not supply a current successful link. A durable attempted marker is not a remote receipt. Read the dedicated getter for current preferences and use observation-only recovery for the original uncertain task.

Cancellation-policy pending claims

They correct admission to the existing cancellation-settings workflow without changing its inputs, transport or task type.

For commerce-ticket-refund-settings, rules and usage share the same policy claim. Status reads historical task progress after current context checks; it performs no fresh policy observation, admission, pre-upgrade enrollment or release. An unresolved save blocks new IDs, other rule selections and matching/inverse no-ops in the same namespace.

A stored done phase can coexist with an owned claim when completion persisted but release failed. Historical status may report stored completion while current verification remains false; it is not permission for a new change. Only original-task recovery may finish that task's release. A prior completed task cannot clear a later task's claim. Keep uncertain journal/claim evidence and the pre-upgrade rollout HOLD. No actual refund, PG, restoration or current-console result follows from this status.

Promotion benefit pending status

Existing benefit profile, activation, connected-product discounts, eligible new connections and relationship disconnection use taskType:"promotion-benefit" and the original taskId. promotion_benefit_apply shares one benefit-wide pending owner within its canonical backend/grant namespace. Status reads stored history without business writes, claim enrollment or claim release. It checks original channel/operator context; another target cannot recover this task.

When the original task still owns the claim, status returns pending with verification.confirmed false even if its completion journal is already done; storedCompletion does not mean claim release succeeded. Without its own claim, stored completion remains historical and has no fresh console link or product/benefit revision. Status cannot release another task's claim. Use original-task recovery, then read the matching benefit or exact products page for fresh state. A changed request ID, product row or action cannot bypass unresolved work on that benefit.

For product-disconnect, a stored relationshipAbsent:true is historical evidence, not current global absence or a deletion performed by this status call. productDeletionPerformed:false and restorationSupported:false remain explicit. Status performs no complete-inventory reconciliation; original-task resume handles that bounded observation. The task retains its original connected-row ID even when completion navigated to a surviving page after the last-page collapse.

For product-connect, stored connectedRelationships and requestedRelationships belong to the original task's history. Status does not reread the complete inventory or selector and does not prove a new save, current relationship identity or live product creation. productCreationPerformed:false and restorationSupported:false remain explicit. Read the matching products/options view for current state; preserve original inputs and use resume for unresolved outcomes.

Additional promotion benefit creation status

promotion_benefit_create uses the existing taskType:"promotion-benefit-create" for ORDER_DISCOUNT and DISCOUNT, including optional initial products. It is separate from the existing-benefit editor's promotion-benefit task and does not provide a campaign-wide creation reservation. Status checks the saved plan, context and receipt consistency, then reports historical prepared, sent or done progress. It performs no creation or fresh product/detail/parent readback; a sent marker is not proof of dispatch.

Saved benefit id/pbid and initial relationship IDs must originate in the authoritative creation receipt. Missing or partial receipt evidence is not repaired from later titles/counts/lists. Historical completion returns no current benefitRevision or successful console destination. Retain original input and taskId, and use observation-only recovery for uncertainty. Current authorization remains required; same-operator credential refresh is tolerated after sent, while prepared work stays bound to the original credentials.