Update: state 4 was eventually fetched on 2 November at 14:19:48 CET, 15h 56m 28s after the 1 November 22:23:20 signal. The notification followed at 14:19:49, without another merchant push, manual refresh or Wallet opening before it. The arrival logs show financed initializing with a different PID but the same boot UUID as yesterday; I don't know why it relaunched. I've retained the arrival log archive if useful.

No fetch in the first two minutes after this restart test. I restarted the iPhone, unlocked it, waited over a minute and left Wallet unopened. Sent one genuine update at 22:23:20 CET (APNs 200); by 22:25:26 there was no list/package request and no visible notification. One correction to the earlier timeline: revision 3 was fetched at 19:06:31. I now recall also restarting the phone around 19:00, so that earlier fetch may have followed a restart; I don't have the exact reboot time.

I've now attached the new diagnostics to FB25380857, along with a detailed timeline, the immediate receipt log excerpt and a before/after scheduler comparison. Both full sysdiagnose archives are in the private report; no device logs are attached here. I ran one further genuine change on the same isolated test order today, 1 November. All times below are CET (UTC+01:00): 17:05:49: published revision 3 and sent one push; APNs returned 200. 17:05:50.548915: the phone's financed Orders handler logged receipt, followed by its ACK at 17:05:50.599025. The topic/type fields are privacy-redacted in this capture. 17:28:05: still no changed-orders or package request. The last completed download remained the original revision 1 from the previous evening. There was no visible update notification. This is only the second accepted update signal on the new Order Type, more than 18 hours after the first. The separate type, single order/service, disabled accepted-push retries and checked power/data settings remain unchanged. The normal sender still uses {}, default priority 10 and no push-type override. For this diagnostic run the phone was USB-connected and unlocked, with Wallet reported backgrounded and no manual refresh; the earlier trial used a locked phone. The new full capture was hardware-triggered at 17:17:44, so 11 minutes 55 seconds after the send, not immediately. I've attached the 17:03:08 pre-signal baseline too. The separate USB archive captured receipt promptly. I want to be clear about that timing limitation. In both powerlog lifecycle selections, the last executed Orders task is still the initial registration on 31 October at 21:21:27. There is no later Orders execution recorded. This does not tell me what is pending in the queue. The daemon is alive, not suspended in the snapshot, and handles other events. Could you look at the private captures and advise which profile or queue/admission-state dump would help distinguish throttling from a missing enqueue/reschedule after receipt? We can run another specific reproduction if needed. I haven't reset the phone, re-added the order or sent more retries.

Thanks for the explanation. I removed the accepted-push retries and ran a new test following your suggestions. Unfortunately, the first update still has not been fetched the next morning. For this test I registered a new Order Type and certificate, with just one synthetic order and one webServiceURL. I removed the previous test orders from the affected iPhone and paused their server workers. The new type had never received a merchant update push before this test. Low Power Mode and Low Data Mode are off, and I have now explicitly checked that Wallet cellular data is enabled. I put Wallet in the background rather than force-quitting it, locked the phone before sending, and have not pulled to refresh or re-added this order. All times below are Europe/Budapest, UTC+01:00, October 31–November 1, 2026, on the same iPhone 16 Pro / build 24B119. There was also an initial registration delay: 20:17:24: added the new order on the Mac. It appeared on the iPhone and produced the initial notification within seconds. 20:17:34: the phone requested and received a token for the new Order Type. Just before the token callback, financed scheduled its next Orders activity with Delay=3599 seconds. 21:21:27: that scheduled activity ran (com.apple.financed.orders.tasks: Run (nudge)), registered with our service (HTTP 201), and fetched revision 1 (HTTP 200). The phone logs confirm this sequence. Wallet entered the foreground later, at 21:22:02. I waited another 71 minutes after registration before the first actual update: 22:32:40: published revision 2, changing the order to a processing shipping fulfillment. updatedAt strictly increased; order ID, authentication token, service URL and createdAt stayed unchanged. Sent exactly one push; APNs returned 200. Body {}, default priority 10, push-type omitted, same production HTTP/2 transport with TLS verification. 22:32:41.281602: financed logged receipt for the new topic. 22:32:41.281973: its Orders handler logged receipt for the new Order Type, followed by an ACK. By 09:14 the next morning, more than 10 hours 40 minutes later, there had been no changed-orders request or package request. The last authenticated response was still revision 1. There was no visible update notification. No confirmation retries, alternate payloads, header probes or further state changes were sent under this new type. The server still records only that one APNs acceptance. I retained the immediate post-push phone log archive and collected a fresh full sysdiagnose at 09:06:46 on November 1 while the order was still stalled. The available overnight unified logs, from midnight to 09:07, show no Orders activity/fetch. The powerlog DAS activity-lifecycle table independently records the 21:21 registration activity, but no later execution of com.apple.financed.orders.tasks, although other background activities continued. The diagnostic snapshot shows financed still running, not suspended. I cannot tell from this whether update work was never queued or was held elsewhere; I do not want to mistake that absence for a proven cause. Could a budget or backoff survive across a newly registered Order Type on the same device, or is there another device-wide limit we should check? Should the first received push in this setup enqueue an Orders task even if the system then delays it? Also, is the roughly one-hour wait for initial registration expected when a new topic token is acquired? FB25380857 is still the existing report. I have the new sysdiagnose and the earlier receipt archive available for private attachment there; they are not attached to this public post. The full sysdiagnose was captured the next morning, not immediately after the signal, so please let me know if you need a new controlled update with a specific logging profile or a particular state dump immediately afterward. We can reproduce this with synthetic orders without touching customer data.