Periodically find and queue missing compiler compatibility checks

Open
  • Is something wrong?
#804 9 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
22/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Domain
backend

Research direction

This is design work, so start by reading the linked #800, #801 and #803 to see what those changes already cover. The issue names no files: look for where the publish job queues compiler matrix jobs and where the existing job queue is written. Done means a design decision on the stateless sweep, the queue-insertion rule, and whether scheduling moves outside the publish job's success boundary, agreed with maintainers before any code is written.

Written by the indexing model from the issue text.

Description

A package can finish publishing, but some of its compiler compatibility checks may never get queued. For example, the server might time out or restart while finding the checks to run. The package is available to users, but its list of supported compilers can remain incomplete indefinitely.

This happened with [email protected] in #800.

#801 makes follow-up scheduling faster and inserts jobs one at a time. That saves jobs already queued before an interruption, but it cannot recover checks it never reached. #803 improves solver performance, but faster solving alone does not repair missing checks.

So the basic problem remains: how do we detect and fix the unavoidable case where a compiler matrix job might not get queued for a published package? And how do we do it without introducing new state?

I think we can accomplish this with a regular, stateless sweep over the registry. The basic idea is to run a small repair command on a regular interval, for example through a systemd timer. Each run starts fresh and asks: Which published package versions still need compiler checks?

For each published package version and each supported compiler:

  1. If the package metadata already lists that exact compiler, skip it.
  2. If a matrix job already exists for that package version and compiler, skip it.
  3. Otherwise, try to find dependency versions that allow a build with that compiler.
  4. If a build plan is found, immediately insert a matrix job into the existing queue.
  5. If no plan is found, leave it alone and try again on a later sweep. A dependency may gain compiler support in the meantime.

The normal server executor still runs the compilation jobs and updates package metadata after successful compilation. The repair command does not compile packages or write compatibility metadata itself.

This survives interruptions itself. As a concrete example, suppose a sweep finds 100 missing checks and stops after queuing 40. The next sweep starts over, skips those 40 existing jobs, and finds the remaining checks. We do not need to remember where the previous sweep stopped.

This also finds old gaps, not just gaps caused by the latest publication or compiler release. It should examine all currently published versions, not only the newest version of each package.

The goal is eventual repair: as sweeps and compilation jobs complete, missing compatibility results are filled in wherever a build succeeds. A missing compiler entry is not proof that the package cannot compile with it, and a solved build plan is not proof of compatibility until compilation succeeds.

Side note: separating queueing from publication success

If publication finishes successfully, a later timeout while queuing compatibility checks currently makes the publish job fail. This is kind of misleading though; the compiler matrix is an eventually-correct best-effort thing, not a requirement for publishing. Compatibility scheduling should be outside the publication job's success/failure boundary and timeout. The periodic sweep can take responsibility for discovering that follow-up work.

The same principle applies to matrix jobs: once compilation succeeds and the compatibility metadata is successfully written/pushed, a later failure to schedule dependant checks should not turn that successful check into a failed job.

Dominant language
PureScript
Stars
95
Forks
79
Avg merge
16h 13m
Merged PRs (30d)
14

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from purescript/registry-dev

All issues in purescript/registry-dev

Similar issues

More Backend & API Design issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.