Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Confirm a slim device is actually slim before it is ready

Aperta
#161 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
ios, typescript

Direzione di ricerca

No files, tests, or entry points are named in the issue. First trace the device readiness and simlock doctor paths, then resolve the open questions before implementation; done means the listed completion conditions hold for slim, full, crash-recovery, and older-runtime cases without Android-specific core changes.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

feature:spec

Request: #152

Problem

A slim device reports featureProfile: "reduced" as soon as the disable commands ran and the device rebooted. Nothing looks at the running device afterwards.

launchctl disable accepts a label the runtime does not have, so a daemon Apple renamed or removed is "disabled" with no effect. A slim device can be heavier than reported, and nobody is told. Operators who size capacity on slim devices lose memory they think they have. Anyone upgrading to a new iOS runtime cannot tell whether slim mode still works there.

Two facts are missing today:

  • After the slim reboot: is every service Simlock meant to disable in fact not running?
  • For an installed runtime: which labels in Simlock's disable list does that runtime not have?

Who it is for

  • Operators who turn on ios.slim.enabled and plan capacity on the savings.
  • Operators upgrading to a new iOS runtime.
  • Agents and people who read featureProfile on a lease.

Outcome

  • Before a slim device is reported ready, Simlock checks the running device against the set it meant to disable. Every lease path goes through readiness, so no lease is granted on an unchecked slim device.
  • A device that passes is reported reduced, as today. The check adds no boot.
  • A device that fails is slimmed and rebooted once more. If it still fails, the device is still ready and the lease is still granted. One event names the device and the services still running.
  • simlock doctor reports, per installed iOS runtime, the labels in the disable list that the runtime does not have. It boots nothing to find out.
  • The check, the event, and the doctor finding have one platform-neutral shape: platform, device, what was expected off, what was found on. A future Android slim mode (#151) reuses them without a core change.

Non-goals

  • Failing a boot or a lease because the check failed. A failed or skipped slim never fails the lease.
  • Re-enabling services, updating the label list, or otherwise fixing drift.
  • Checking --full devices, crash-recovery reboots, or runtimes below iOS 18.5. Nothing was applied on them.
  • Checking a device again after it is ready, or while it is leased.
  • Measuring memory or process counts. The check is per service, not per byte.
  • Android slim mode itself (#151).

Completion conditions

  • With slim on, a device whose whole disable set is off after the slim reboot is granted with featureProfile: "reduced", and simlock events shows device.slimmed and no failure event for that boot.
  • When a service in the disable set is still running after the slim reboot, Simlock applies the set and reboots once more before the device is ready.
  • When a service is still running after that retry, the lease is granted, and simlock events shows exactly one event for that boot naming the device and every service still running.
  • A check that passes on the first try adds no boot to the lease.
  • With slim on, simlock doctor names each installed iOS runtime that lacks a label from the disable list, and the missing labels, without booting a device. With slim off it reports nothing.
  • A --full lease, a crash-recovery reboot, and a boot on a runtime below iOS 18.5 produce no check, no retry, and no event.
  • The event payload and the doctor finding carry the same fields for every platform, and nothing outside the iOS driver names launchd.

Open questions

  1. After a failed retry, is the device reported reduced or full? Recommended: reduced. The services that did stop are gone, and a false full makes push or StoreKit fail with no explanation (ADR 0002 point 10 reasons the same way).
  2. Does doctor report drift for a runtime no device has booted on yet? Recommended: yes. Drift is a property of the installed runtime and should be visible before the first lease.
  3. Does a label the runtime does not have count as passing the readiness check? Recommended: yes. It cannot be running. It is drift, which doctor reports, not a failed check.
  4. After a failed retry, does the next plain reboot of that device (idle shutdown, then boot, no erase) run the whole pass again, or trust the idempotence marker? Recommended: trust the marker. The event is the record, and a device that cannot converge would otherwise cost three boots on every boot.
  5. When the first check fails and the retry passes, is that visible? Recommended: no separate event; device.slimmed says the pass took two attempts.

Written by an agent.

Lingua principale
TypeScript
Stelle
14
Fork
0
Merge medio
1g 3h
PR unite (30g)
49

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di callstackincubator/simlock

Tutte le issue di callstackincubator/simlock

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.