Code-execution Python probe should assert a minimum interpreter version (curriculum uses 3.10+ match) #379

New Issue

2026-07-05T08:27:26Z

spikerj commented

2026-07-05 08:27:26 +00:00

Symptom

The Python curriculum uses match statements (structural pattern matching), which require Python 3.10+ — e.g. the seeded reference solutions in CurriculumBookCatalog.cs / CurriculumTextSeed.cs. On any deployment whose CodeExecution.PythonExecutable resolves to an older interpreter (observed locally with Python 3.9.6), students hit SyntaxError: invalid syntax on match event: for those lessons — with no operator signal.

Gap

PythonInterpreterProbeHostedService (in SpikerSoft.EventHandlers.CodeExecution) is a good boot-time degrade-loudly guard, but it only checks that the interpreter runs — it logs the version string and returns. It does not assert the version is new enough for the curriculum. So an old-but-present Python passes the probe, then silently fails kids mid-lesson. There is no MinimumPythonVersion config or version gate anywhere.

Fix (this ticket)

Add CodeExecution:MinimumPythonVersion config (default 3.10, documenting the curriculum's match requirement).
A pure, unit-tested PythonVersionGate helper: parse the python --version output (Python 3.11.2 → 3.11; handles stdout/stderr, junk, nulls) and compare to the configured floor.
Wire it into the boot probe: when the resolved interpreter is below the floor, log a loud, actionable WARNING naming the required version (non-fatal, matching the existing probe design so C# lessons keep working) instead of the current bare "ready" info line.

This is the same honesty/degrade-loudly posture as the Redis healthcheck (#372) and NodeAgent (#375) work: surface a silent failure at boot so ops (or a future auto-remediation sweep) can act, rather than letting students be the detector.

Not in scope

Making the probe fatal (kept non-fatal by design); bumping the actual deployed interpreter (that's an infra/Dockerfile action, surfaced by the new warning).

## Symptom The Python curriculum uses `match` statements (structural pattern matching), which require **Python 3.10+** — e.g. the seeded reference solutions in `CurriculumBookCatalog.cs` / `CurriculumTextSeed.cs`. On any deployment whose `CodeExecution.PythonExecutable` resolves to an older interpreter (observed locally with Python 3.9.6), students hit `SyntaxError: invalid syntax` on `match event:` for those lessons — with no operator signal. ## Gap `PythonInterpreterProbeHostedService` (in `SpikerSoft.EventHandlers.CodeExecution`) is a good boot-time degrade-loudly guard, but it only checks that the interpreter **runs** — it logs the version string and returns. It does **not** assert the version is new enough for the curriculum. So an old-but-present Python passes the probe, then silently fails kids mid-lesson. There is no `MinimumPythonVersion` config or version gate anywhere. ## Fix (this ticket) - Add `CodeExecution:MinimumPythonVersion` config (default `3.10`, documenting the curriculum's `match` requirement). - A pure, unit-tested `PythonVersionGate` helper: parse the `python --version` output (`Python 3.11.2` → `3.11`; handles stdout/stderr, junk, nulls) and compare to the configured floor. - Wire it into the boot probe: when the resolved interpreter is below the floor, log a **loud, actionable WARNING** naming the required version (non-fatal, matching the existing probe design so C# lessons keep working) instead of the current bare "ready" info line. This is the same honesty/degrade-loudly posture as the Redis healthcheck (#372) and NodeAgent (#375) work: surface a silent failure at boot so ops (or a future auto-remediation sweep) can act, rather than letting students be the detector. ## Not in scope Making the probe fatal (kept non-fatal by design); bumping the actual deployed interpreter (that's an infra/Dockerfile action, surfaced by the new warning).

spikerj commented

2026-07-05 08:31:39 +00:00

Resolved in spikersoft-backend PR #91 (merged to master). Added the pure PythonVersionGate (parse python --version, compare by major.minor), a CodeExecution:MinimumPythonVersion floor (default 3.10), and wired it into PythonInterpreterProbeHostedService — below-floor now logs a loud actionable WARNING at boot (non-fatal) instead of letting students hit SyntaxError on match. 21 new tests. Closing.

Follow-up (infra, not this ticket): ensure the CodeExecution worker's base image ships python3 ≥ 3.10 — the new boot warning makes a too-old interpreter visible in Seq if any deployment doesn't.

Resolved in spikersoft-backend PR #91 (merged to `master`). Added the pure `PythonVersionGate` (parse `python --version`, compare by major.minor), a `CodeExecution:MinimumPythonVersion` floor (default 3.10), and wired it into `PythonInterpreterProbeHostedService` — below-floor now logs a loud actionable WARNING at boot (non-fatal) instead of letting students hit `SyntaxError` on `match`. 21 new tests. Closing. Follow-up (infra, not this ticket): ensure the CodeExecution worker's base image ships python3 ≥ 3.10 — the new boot warning makes a too-old interpreter visible in Seq if any deployment doesn't.

spikerj closed this issue

2026-07-05 08:31:43 +00:00

spikerj referenced this issue

2026-07-17 20:05:28 +00:00

perf(keycloak): cache JsonSerializerOptions instead of per-call allocation (CA1869) #681

spikerj referenced this issue

2026-07-17 20:07:27 +00:00

perf(mcp): cache CalendarTools JsonSerializerOptions instead of per-call allocation (CA1869) #682

Sign in to join this conversation.