3.3 KiB
Promptkit v0.23.0
This minor release adds optional whole-operation timeouts and prepared-request notifications to ordinary and coordinated execution. Applications can bound each continuation independently and retain the request selected for execution without replacing Promptkit's turn loop or preparing the same request twice.
Bound Individual Operations
RunRequest.OperationTimeout selects a fresh cooperative budget covering
preparation and execution, including capacity waiting, retries, validation,
structural repair, and prepared-request notification. It is independent of the
provider generation timeout. Zero or negative values select no additional
timeout; existing parent cancellation and earlier deadlines remain effective.
For split execution, PrepareExecution retains the duration without starting
a timer. RunPrepared starts that budget after claiming the handle, so prior
preparation and idle time do not consume it. Callers can still supply one shared
deadline context to bound both calls together.
Local budget failures match both ErrOperationTimeout and
context.DeadlineExceeded. Each coordinated turn uses its selected budget;
expiry stops that coordination through the existing operational-error path
without canceling its parent or sibling work. Completed outcomes are fixed
before terminal observation and are not changed by a slow terminal observer.
Cancellation does not forcibly interrupt callbacks or collaborators that ignore
their context.
See the execution-controls guide and the public request contract and timeout error contract for exact behavior.
Retain Prepared Details Before Generation
RunRequest.OnPrepared optionally receives a detached, credential-redacted
PreparedRun and the operation context before first generation. It uses the
actual prepared snapshot, including continuation history, without rereading
inputs or rerendering. Applications may retain these details even if generation
later fails without returning a result.
Notification is synchronous, at most once per logical execution, and runs while logical admission is held. It is not repeated for retries or structural repair. Preparation or admission failure can prevent delivery. The application owns diagnostic storage and disclosure decisions; ordinary observers remain metadata-only. See the OnPrepared GoDoc and updated offline observation example.
Compatibility And Upgrade
Both controls are opt-in. Existing keyed requests and configuration files need
no migration from v0.22.0. Prepare and ValidateRequest continue using only
their supplied contexts and do not invoke OnPrepared. RunRequest gained
fields; consumers using positional struct literals must switch to keyed
literals. Prepared/result JSON representations are unchanged.
The Go consumer minimum remains 1.27.0, and dependency versions are unchanged.
go get go.maximumdirect.net/promptkit@v0.23.0