Skip to main content

K12 Persistence & Monitoring

Primary tables​

  • K12SAFETY.log_Jobs — Job-level rows created by the kickoff runner. Holds request_id (PK), session_id, workflow_run_id, status, error, input_payload, result_payload, timestamps and attempt_count.
  • K12SAFETY.log_EOP_TaskRequests — Stores normalized request payloads and the Response* fields written back by k12-update-task-request-response (columns include RequestID, SessionID, RequestFormFieldContent, ResponseStatus, ResponseMessage, ResponsePayloadJson, etc.).
  • K12SAFETY.log_EOP_TaskStatus — Monitoring table used to track the processing timeline (status history rows: accepted, processing, success, failed, cancelled).

DDL excerpt (jobs table)​

The log_Jobs table is created with columns similar to:

CREATE TABLE K12SAFETY.log_Jobs (
  request_id NVARCHAR(64) PRIMARY KEY,
  session_id NVARCHAR(64) NULL,
  workflow_run_id NVARCHAR(64) NULL,
  job_type NVARCHAR(64) NOT NULL,
  job_description NVARCHAR(256) NULL,
  status NVARCHAR(32) NOT NULL,
  status_message NVARCHAR(512) NULL,
  input_payload NVARCHAR(MAX) NULL,
  result_payload NVARCHAR(MAX) NULL,
  error NVARCHAR(MAX) NULL,
  attempt_count INT NOT NULL DEFAULT (0)
);

How they interact​

  • Kickoff inserts rows in log_Jobs (runner) and log_EOP_TaskRequests (request logging).
  • log_EOP_TaskStatus receives a processing entry early and is updated to success/failed once the run finishes.
  • lookup-task-request-result and k12-annex-editing-result return normalized values from log_EOP_TaskRequests or log_Jobs.result_payload depending on which API is used.

Diagnostics​

  • Query the latest status using k12-lkp-task-status-by-session-or-request (tool) to see history entries.
  • If a result is missing, check log_Jobs.result_payload and the serialized ResponsePayloadJson fields in log_EOP_TaskRequests.
  • For QRG persistence details, see the QRG database page.
  • For sample SQL diagnostic queries, see the debug playbooks in the EOP database page and QRG analysis page.