Module credit_registration 

The credit registration pipeline’s rules, which the worker crate’s phases apply.

The pure half decides what each move does to a row (outcomes), how long to wait and what may be retried (backoff, classification), what gets registered (payload, grade_mapping, enrolment_selection), and what of an exchange may be kept (scrub). The rest are database steps the phases run, such as materialize, preconditions, enrolment_checks and account_linking. Every state change goes through credit_registrations::transition.

Re-exports

pub use pending_reason::CreditRegistrationPendingReason;

pub use pending_reason::PendingPreconditions;

pub use pending_reason::PendingReasonCounts;

pub use student_facing_status::StageMatch;

pub use student_facing_status::StudentFacingCreditRegistrationStatus;

Modules

account_linking

Claiming the right to mail a Sisu person an account-linking link, and minting the token it carries. Both caps and the dedup guard are evaluated here and nowhere else, and no argument switches them off; an override has to soft-delete a ledger row.

backoff

How long the pipeline waits before trying again. Generic scheduling math; which error codes are even retryable is super::classification.

classification

What may be done about a ledger error code: the one place retryability is decided. How long to wait is super::backoff; which Suotar codes map to which error code is the worker’s Suotar adapter’s.

config_validation

Deciding whether one module’s credit-registration configuration is usable.

course_unit_poll_slots

When a partially registered row next looks for its course unit attainment. Sisu creates those in a nightly batch, so a row polls once after it, on the morning slot, and again on the noon slot if the morning poll came too early. A row that first shows its assessment item attainment during the day waits for the next morning.

enrolment_check_schedule

When a row waiting for an enrolment is checked next.

enrolment_checks

Moving one row’s enrolment check schedule: starting it, restarting it for a visit or a check request, scheduling the next check once one answers, batching slow checks, waking rows off a roster and shifting them past a module pause. The ladders are super::enrolment_check_schedule.

enrolment_selection

Which of a student’s enrolments the attainment is registered against. A study right that covers the attainment date first, since Sisu refuses one that does not; then degree before open university: a degree student who also holds an open-university study right wants the credit inside their degree.

grade_mapping

Our grade in the study registry’s terms. Every pair that reaches a batch has been through map_grade or is_known_grade.

legacy_mirror

Mirroring our successes into the legacy study-registry ledger. The mirror row makes the registry’s own ?exclude_already_registered=true skip the completion, keeps the teacher views’ existing registered flag working, and gives support the real student number.

materialize

Creating ledger rows for completions that are allowed to be registered. It catches up as well as keeps up: any completion carrying the push-path flag and still missing a row gets one, stopping at pending, because historical completions belong to students nobody ever asked. Completions from before the push path never carry the flag, so they are never caught up.

outcomes

Every move the pipeline makes on one ledger row, decided apart from the phases that apply it: what an answer from the study registry does to its row, and the moves a phase makes without asking. No outcome here may return a state that leads back to import: a row whose import may have landed must never be sent again. The one exception is verify’s notRegistered, which is the registry itself saying the submission did not land.

payload

The frozen copy of what we submit: written once before the row leaves enrolment resolution and never rewritten, so a later regrade cannot silently change something already sent.

pending_reason

Why a pending ledger row is still pending.

preconditions

Moving a row along, or out of, the chain of things that must be true before we submit. Decided from the database alone, so it keeps running during a Suotar outage.

scrub

Removing personal data from what the credit registration pipeline keeps of its Suotar exchanges: the call log’s bodies, the ledger’s event details and error messages.

sisu_day_gap

The nightly hours when Finland is already on the next day but Sisu, which dates attainments by the UTC day, is not: 00:00–03:00 Finnish time in summer, 00:00–02:00 in winter. Suotar dates an attainment by its Finnish day, so one dated today is in the future for Sisu then, and Sisu refuses it. Importing waits the gap out.

sisu_name

What linking a student number does to the account’s name: the name follows Sisu, which verifies identity strongly, while the account’s own name is whatever the student once typed.

student_facing_status

What a student is told about one credit registration. Computed here rather than in the frontend so a new ledger state has to be classified before it compiles.

student_notifications

The two terminal-state mails a student may get about a credit registration.

student_number

Catching typos in a student number a person types: today’s University of Helsinki numbers are a 0 and eight digits, the last a check digit.

student_number_change

What changing an account’s linked student number does to its registrations: both the student’s own unlink/claim and an admin’s unlink/manual-link go through this, so the audit trail and the recompute stay in one place regardless of who acted.

student_progress

The step list a student sees once their registration has found an enrolment. Classified here so a new ledger state has to be placed on it before it compiles.

study_registry

What the study registry answers, in the pipeline’s own terms. The credit registration worker’s Suotar adapter reads Suotar’s wire records into these; nothing here knows the wire format.

submission_context

Everything a submission needs that does not live on the ledger row yet. One query rather than a lookup per row: the phases work in batches of up to a thousand.

timeline

Where a registration stands on the admin timeline. Derived from the ledger state and the preconditions rather than stored, so a new ledger state has to be placed on the timeline before it compiles, and every admin surface (lists, counts, the registration page) places it alike.