Skip to content

updating remote-override branches - #3

Closed
Kdisimone wants to merge 1 commit into
LoopKit:remote-overridesfrom
Kdisimone:update-submodules
Closed

Kdisimone wants to merge 1 commit into
LoopKit:remote-overridesfrom
Kdisimone:update-submodules

Conversation

@Kdisimone

Copy link
Copy Markdown

No description provided.

@Kdisimone

Copy link
Copy Markdown
Author

Remote-overrides was coming in with master branches.

@ps2 ps2 closed this May 19, 2020
ddaniels1 pushed a commit to ddaniels1/LoopWorkspace that referenced this pull request May 23, 2020
treed6386 added a commit to treed6386/LoopWorkspace that referenced this pull request Jan 7, 2024
treed6386 added a commit to treed6386/LoopWorkspace that referenced this pull request Jan 7, 2024
codebymini pushed a commit to codebymini/LoopWorkspace that referenced this pull request Sep 2, 2025
codebymini pushed a commit to codebymini/LoopWorkspace that referenced this pull request Sep 2, 2025
kinterra added a commit to kinterra-org/LoopWorkspace that referenced this pull request Jan 28, 2026
fix alignment. L&L code copy & paste failed.
threecee pushed a commit to threecee/LoopWorkspace that referenced this pull request May 2, 2026
Picks up:
- OmniBLE (b4-start..5fb011a, 4 commits): payload validity 60s → 600s
  + doc comment (LoopKit#6); PhoneWatchSettingsSync v2 with automaticDosing
  fields + protocol version bump (LoopKit#3); shared HandoffState.currentOwner
  extension for policy-engine wiring (LoopKit#2).
- Loop (b4-start..b5e94f7a, 4 commits): iOS LoopAppManager wires
  settingsSyncProvider closure (closes production gap discovered
  during planning) + watch WatchSettingsSnapshot reads dosing flags
  from sync (LoopKit#3); HandoffOrchestrator wires HandoffPolicyEngine
  markX hooks on both sides via Combine reachability subscription
  with 60s debounce (LoopKit#2); review-fix renames + safety comment.

After this, the watch can self-drive when the phone reports
automaticDosingEnabled, the auto-revert path is live (was dead code
since B.3.a), and the cached-pod-state safety gate is active.

BEHAVIOR CHANGE: auto-revert from watch back to phone WILL FIRE in
.automatic and .manualWithAutoRevert modes when the phone reconnects
after being out of range for >=60s. Worth deliberate hardware testing
on the next install.

Verified:
- OmniBLETests targeted (3 suites): 26/26 PASS
- LoopTests targeted (3 suites): 27/27 PASS
- WatchApp ExtensionTests targeted (2 suites): 19/19 PASS
- Release archive: ARCHIVE SUCCEEDED (iOS, generic destination)

threecee-claude
threecee pushed a commit to threecee/LoopWorkspace that referenced this pull request May 2, 2026
Picks up:

- OmniBLE (b5.2-start..HEAD, 2 commits): commandsAllowedCheck gate
  widened to runTemporaryBasalProgram, cancelBolus, suspendDelivery
  (#5b); PhoneWatchSettingsSync.timeZone: String? field + protocol
  bump 3 -> 4 (LoopKit#3).

- Loop (b5.2-start..HEAD, 1 commit): HandoffBlockedError +
  StatusTableViewController handoff-blocked rendering for cancelBolus
  (#5b); HandoffOrchestrator + LoopAppManager populate timeZone (LoopKit#3) +
  observe NSSystemTimeZoneDidChangeNotification (#3b);
  WatchAlgorithmDriver resolves scheduleZone from sync.timeZone and
  threads to all 4 dailyItems schedule constructors (LoopKit#3).

After this:
- The 3 newly-gated pump methods short-circuit during the sub-second
  handoff window. cancelBolus's iOS UI renders "Handoff in progress,
  please try again in a moment" via HandoffBlockedError; suspendDelivery
  is OmniBLE-PumpManagerUI-only (out of Loop UI scope).
- Watch interprets all 4 dailyItems schedules in the phone's zone;
  phone-side TZ changes propagate to the watch within one WCSession
  round-trip via the new NSSystemTimeZoneDidChangeNotification observer.

Verified:
- OmniBLETests targeted: all suites green (104 tests; WatchAlgorithmEndToEndTests
  5/5 after retry to clear cold-start noPodsFound flake)
- LoopTests targeted: 31/31 green
- WatchApp ExtensionTests targeted: 36/36 green
- Release archive: ARCHIVE SUCCEEDED (iOS, generic destination)

threecee-claude
threecee pushed a commit to threecee/LoopWorkspace that referenced this pull request May 3, 2026
…nciliation

Loop: AlgorithmStateSnapshotEmitter populates rolling buffers from
runner inputs. WatchAlgorithmDriver.applyAlgorithmStateSnapshot writes
buffers to watch stores via upstream LoopKit batch-insert APIs (with
NewGlucoseSample/NewCarbEntry projections; doses pass through).
WatchAlgorithmDriver's .skipWarmup case hydrates inside the switch
(snapshot is in scope via WarmUpDecision's associated value). Phase 6
caught + fixed a production bug: DoseStore.addDoses calls its
completion handler twice; Phase 3's continuation now NSLock-guarded.

Wire format: file-pointer fallback for oversized snapshots (Phase 1
measured 21.25KB; >8KB threshold). Phone writes to AppGroup/snapshot.json,
sends pointer message via applicationContext. Watch reads file on
pointer receipt, validates monotonic sequence.

LoopAlgorithmReconciliationTests harness ships with placeholder fixtures
+ stub runForReconciliation body. Tests XCTSkip cleanly. Real fixtures
captured manually via Phase 5a's #if DEBUG instrumentation in follow-up.

OmniBLE: AlgorithmStateSnapshot.isFreshEnoughForSkipWarmup helper.
PhoneWatchMessage.algorithmStateSnapshotPointer(sequence:) wire-format
case + PhoneWatchProtocol.currentVersion bumped 5 to 6.

Closes Codex adversarial review Loop LoopKit#3 high. Closes the umbrella
B.8.x adversarial-review-hardening series. algorithm-fidelity-audit
PASS verified at /tmp/algorithm-fidelity-audit-2026-05-03.md.

Tagged b8.4-complete on all three repos. Build 876 prep.

threecee-claude
jeremybarnum pushed a commit to jeremybarnum/LoopWorkspace that referenced this pull request Aug 19, 2026
Jeremy: 'we should start a UX list of nice to haves... so that people's first
experience is good.' Seven entries from the last two days, each with what the user
sees, why it happens, and a candidate fix with its cost named.

The first-loan-after-install slowness is LoopKit#1, with pre-warm as the candidate -- and a
gate on it: do not build until the discovery question is settled, because if watchOS
throttles background scanning then a pre-warm arms a scan that hears nothing.

Two entries are the same bug in different clothes (LoopKit#4 frozen glance, LoopKit#5 unresponsive
closed-loop tap), both from the glance ticking on the queue the pod ladder holds.

LoopKit#3 is worth doing whatever happens to the transport bug: a UI that cannot say 'you
are fine' during a state that IS fine is a UI that manufactures alarm.
jeremybarnum pushed a commit to jeremybarnum/LoopWorkspace that referenced this pull request Aug 29, 2026
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
ps2 added a commit that referenced this pull request Aug 30, 2026
Building with Xcode 27 (27A5237l) failed before reaching any of our
code:

  TrueTime.xcodeproj: error: The iOS deployment target
  'IPHONEOS_DEPLOYMENT_TARGET' is set to 12.0, but the range of
  supported deployment target versions is 15.0 to 27.0.x.
  (in target 'TrueTime-iOS')

Upstream fixed this in "bump deployment (#3)", which raises the target
from 12.0 to 15.0 and changes nothing else. Testers already building
with Xcode 27 are on that commit.

Xcode 26 was unaffected, which is why this went unnoticed.
@ps2 ps2 mentioned this pull request Aug 31, 2026
unpeng added a commit to unpeng/LoopWorkspace that referenced this pull request Oct 3, 2026
根因: 上游 715b7ca7(Xcode 27 Build Support) 把 App 初始化推迟到
SceneDelegate.scene(_:willConnectTo:)。息屏被静默推送唤醒时 scene 不会连接,
deviceDataManager 为 nil,而 handleRemoteNotification 用可选链静默丢弃通知却仍
返回 true(向系统上报成功),指令未执行且无任何日志痕迹。影响 v3.14.7 / v3.14.8
(v3.14.2 及更早不含 SceneDelegate,不受此根因影响)。

LoopKit#1 后台启动路径(LoopAppManager/SceneDelegate):
  - 新增 launchManagersForBackgroundWork(launchOptions:),只推进到 managers 就绪
    (deviceDataManager 可用),停在 .launchOnboarding,不创建主界面
  - initialize 的 windowProvider 改为可选(后台无窗口)
  - SceneDelegate 连接时 registerWindowProvider(self) 补登 window,并在
    isLaunchPending 为 false 时 resumeLaunchFromCurrentState() 跑完 UI 阶段
    (否则后台已初始化过 => 主界面永远建不起来)

LoopKit#3 挂起竞态(AppDelegate/ServicesManager):
  - 新增 RemoteNotificationDispatchToken: 在 didReceiveRemoteNotification 返回前
    同步取得后台断言,避免 App 在异步处理任务排到之前被挂起
  - completionHandler 推迟到处理真正结束,幂等 + 25s 超时兜底
  - ServicesManager 用 defer 保证所有退出路径都回调

LoopKit#2 诊断日志: 唤醒时的 appState/剩余后台时间/启动阶段、manager 是否为 nil、
  后台断言是否取得、各阶段耗时与最终上报结果。nil 分支改为返回 false(上报 .failed)。

验证: 编译通过;模拟器主界面正常启动(验证 windowProvider 补登有效)、无断言失败。
未验证: 远程通知路径无法在模拟器验证 —— Loop 在 targetEnvironment(simulator) 下
不调用 registerForRemoteNotifications(),didReceiveRemoteNotification 永不触发。
需真机配合系统日志(筛选 "Remote Notification:")确认。
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants