Post

Replies

Boosts

Views

Activity

Reply to Live Caller ID Lookup: App Store build fails with "Proxies not present, but required to fail closed" while development build works
Update: A/B experiment on the same device, three minutes apart To rule out anything on our side, we injected a known record into our live PIR corpus, reprocessed the affected shard, restarted the service, and then placed a real incoming call from that number to the same test iPhone twice: once with the Xcode-signed build installed, once with the App Store build of the same version (14, build 36). Xcode-signed, 15:45:29 App Store, 15:48:07 Result POST /queries served, name shown on the incoming call screen requestData(byKeywords:shardIds:clientConfig:) → -1009 Proxies not present, but required to fail closed 0 94 Connections stamped proxy fail closed 0 47 nw_endpoint_proxy_add_config_if_applicable for our extension n/a (direct) 0 Interface Wi-Fi (en0) cellular (pdp_ip0, 5G) Server side over those same three minutes: 15:45:29 POST /queries <- Xcode build, answered, name returned 15:46:41 GET /.well-known/... <- App Store build, directory only 15:46:45 GET /.well-known/... 15:46:50 GET /.well-known/... (nothing else, ever) Everything is held constant except the code signature: same device, same iOS build, same Apple ID, same corpus record, same backend, same calling number, minutes apart. The failure is not limited to token acquisition. Three different endpoints across two hosts fail with the same proxy error: NSErrorFailingURLKey=https://<our-pir-host>/queries NSErrorFailingURLKey=https://<our-pir-host>/config NSErrorFailingURLKey=https://<our-issuer-host>/token-key-for-user-token Full error, the lookup call itself, on cellular: requestData(byKeywords:shardIds:clientConfig:) threw an error: Error Domain=NSURLErrorDomain Code=-1009 "The Internet connection appears to be offline." UserInfo={_NSURLErrorNWPathKey=satisfied (Path is satisfied), interface: pdp_ip0[endc_sub6], ipv4, dns, expensive, uses cell, estimated upload: 524288Bps, estimated download: 8388608Bps, LQM: minimal, NSErrorFailingURLKey=https://<our-pir-host>/queries, NSUnderlyingError={Error Domain=NSPOSIXErrorDomain Code=50 "Network is down"}, _NSURLErrorPrivacyProxyFailureKey=true, NSLocalizedDescription=The Internet connection appears to be offline.} And the same on Wi-Fi with a healthy link: interface: en0[802.11], ipv4, dns, uses wifi, LQM: good NSErrorFailingURLKey=https://<our-issuer-host>/token-key-for-user-token NSUnderlyingError={NSPOSIXErrorDomain Code=50 "Network is down"} _NSURLErrorPrivacyProxyFailureKey=true Note that _NSURLErrorNWPathKey reports the path as satisfied in every case, so the "offline" description is a downstream effect of the fail-closed proxy requirement, not a real connectivity problem. A sysdiagnose and the raw device log captures are available on request, and are attached to FB24501570.
2d
Reply to Live Caller ID Lookup: App Store build fails with "Proxies not present, but required to fail closed" while development build works
Update: A/B experiment on the same device, three minutes apart To rule out anything on our side, we injected a known record into our live PIR corpus, reprocessed the affected shard, restarted the service, and then placed a real incoming call from that number to the same test iPhone twice: once with the Xcode-signed build installed, once with the App Store build of the same version (14, build 36). Xcode-signed, 15:45:29 App Store, 15:48:07 Result POST /queries served, name shown on the incoming call screen requestData(byKeywords:shardIds:clientConfig:) → -1009 Proxies not present, but required to fail closed 0 94 Connections stamped proxy fail closed 0 47 nw_endpoint_proxy_add_config_if_applicable for our extension n/a (direct) 0 Interface Wi-Fi (en0) cellular (pdp_ip0, 5G) Server side over those same three minutes: 15:45:29 POST /queries <- Xcode build, answered, name returned 15:46:41 GET /.well-known/... <- App Store build, directory only 15:46:45 GET /.well-known/... 15:46:50 GET /.well-known/... (nothing else, ever) Everything is held constant except the code signature: same device, same iOS build, same Apple ID, same corpus record, same backend, same calling number, minutes apart. The failure is not limited to token acquisition. Three different endpoints across two hosts fail with the same proxy error: NSErrorFailingURLKey=https://<our-pir-host>/queries NSErrorFailingURLKey=https://<our-pir-host>/config NSErrorFailingURLKey=https://<our-issuer-host>/token-key-for-user-token Full error, the lookup call itself, on cellular: requestData(byKeywords:shardIds:clientConfig:) threw an error: Error Domain=NSURLErrorDomain Code=-1009 "The Internet connection appears to be offline." UserInfo={_NSURLErrorNWPathKey=satisfied (Path is satisfied), interface: pdp_ip0[endc_sub6], ipv4, dns, expensive, uses cell, estimated upload: 524288Bps, estimated download: 8388608Bps, LQM: minimal, NSErrorFailingURLKey=https://<our-pir-host>/queries, NSUnderlyingError={Error Domain=NSPOSIXErrorDomain Code=50 "Network is down"}, _NSURLErrorPrivacyProxyFailureKey=true, NSLocalizedDescription=The Internet connection appears to be offline.} And the same on Wi-Fi with a healthy link: interface: en0[802.11], ipv4, dns, uses wifi, LQM: good NSErrorFailingURLKey=https://<our-issuer-host>/token-key-for-user-token NSUnderlyingError={NSPOSIXErrorDomain Code=50 "Network is down"} _NSURLErrorPrivacyProxyFailureKey=true Note that _NSURLErrorNWPathKey reports the path as satisfied in every case, so the "offline" description is a downstream effect of the fail-closed proxy requirement, not a real connectivity problem. A sysdiagnose and the raw device log captures are available on request, and are attached to FB24501570.
Replies
Boosts
Views
Activity
2d