From d88b9cb31fd7ee2d1fc666c257d77ebbf16c7f25 Mon Sep 17 00:00:00 2001 From: Rongsong Shen Date: Mon, 12 Oct 2026 10:09:38 +0000 Subject: [PATCH] docs(spec): application-profile: dispatch-window handling and profile content hash - profile gone or changed between scheduler decision and controller dispatch: dispatch fails (retryable) and the job returns to PEND via requeue, never EXIT - internal per-profile content hash (canonical capnp, excluding description) carried on the dispatch decision and the dispatch record Co-Authored-By: Claude Opus 5.5 (1M context) --- .kiro/specs/application-profile/brief.md | 36 +++++++++++++++++++++++- 1 file changed, 35 insertions(+), 1 deletion(-) diff --git a/.kiro/specs/application-profile/brief.md b/.kiro/specs/application-profile/brief.md index a3aadb51..d8682c58 100644 --- a/.kiro/specs/application-profile/brief.md +++ b/.kiro/specs/application-profile/brief.md @@ -365,7 +365,8 @@ restarted, and the scheduler no longer re-merges it. `rusage[license=1]`) do not change when the profile changes, and are rebuilt identically after a scheduler failover or restart; - execution: mode, mode options, launch type, env, outer pre/post-exec, - limits. + limits; + - the profile content hash the record was built from. - At each dispatch the controller puts the execution values into the job's `start_info` for the worker, and the whole record into an additive payload on the WAL dispatch fact @@ -399,6 +400,39 @@ with the reason "application profile X is not defined". pending jobs or services, with counts; `xceadmin config upgrade` prints it. Needs a new scheduler pend reason (profile missing from `Conf4Sched`). +- **Between the scheduler's decision and the controller's dispatch** + (decided 2026-10-12, user). The scheduler merges with its copy of the + profile (`Conf4Sched`); the controller reads the profile again when it + builds the dispatch record. If the profile is gone or has changed in + between, the **dispatch fails and the job goes back to PEND through the + requeue path** (re-reading the profile, as any requeue does): gone → it + pends with "application profile X is not defined"; changed → the + scheduler re-merges with the new profile. Never EXIT. + - New dispatch failure site (e.g. `XCE_DISPATCH_FAIL_SITE_APP_PROFILE`), + classified retryable, unlike today's terminal + `XCE_DISPATCH_FAIL_SITE_QUEUE_EXEC` (`controller/job.c`). Nothing is + committed on this path (`j->job.allocs` is committed only after a + successful `xce_startjob_req()`). Requirements decide that it does not + count as a run or against requeue limits. + - A scheduler still on the old config may re-dispatch and be declined + again until the controller's config push reaches it; the existing + dispatch retry backoff bounds that. + - After the controller has built the record, profile changes no longer + matter: the worker starts from `start_info`. +- **Profile content hash** (decided 2026-10-12, user): an internal version + of each profile. + - Computed, never stored as state: one `src/lib` function hashes the + canonical Cap'n Proto encoding of the profile, excluding + `description`. Controller, scheduler and apiserver get the same value + from the same profile, also after failover or restart. + - The scheduler's dispatch decision carries the hash it merged with + (additive field); the controller compares it with the current + profile's hash at dispatch. A scheduler that sends no hash (rolling + upgrade) skips the check. + - The dispatch record stores it; "profile changed since dispatch" in job + details is a hash comparison; job details show it short + (`openfoam@3f2a9c`). Admins never set it. + - Base for the open "profile versioning and audit" item. - Leaning, for requirements: `jobmod --app ` moves a pending job to another profile (the owner, with `app:use` on the new one; admins in bulk, e.g. `--app-from `); the scheduler re-evaluates.