I'm building a Matter irrigation system and I've hit a device-type wall in the Home app. This is not a commissioning or pairing problem - the accessory is found, setup proceeds, and then Home declines to create the accessory, reporting that the device is not supported. The controlled comparison, which is why I'm confident it is the device type and nothing else: Endpoint declares 0x0042 Water Valve (Matter 1.3) with cluster 0x0081 Valve Configuration and Control -> Home: NOT SUPPORTED, accessory is not created. Endpoint declares 0x010A On/Off Plug-in Unit with cluster 0x0006 On/Off -> Home: created, works, valve opens and closes. Same hardware, same firmware image, same network, same iPhone. The only variable is the device type ID. Other Matter controllers accept the 0x0042 version and control it correctly. Water Valve (0x0042) - is this device type supported by the Home app in any current or announced iOS version? If not, is support planned? Right now I ship the plug-in-unit substitution because it is the only thing Home will accept. It works, but it misrepresents the device: the user sees a row of "plugs" that are actually irrigation valves, with no valve semantics and nothing telling Home - or an automation the user writes - that switching this on releases water into a garden. Soil Sensor (Matter 1.5) - same question. Matter 1.5 added soil sensing (moisture, optionally temperature), explicitly positioned for irrigation paired with Matter water valves. Is it supported or planned in Home? Today I publish soil moisture on a Relative Humidity Measurement endpoint (0x0405) because that is what Home renders, so garden soil moisture appears as air humidity and pollutes any humidity-based automation the user has. The general question, which is the one I actually want answered: is there an authoritative list of the Matter device type IDs the Home app accepts? The public support article describes categories in prose (lights, plugs, switches, thermostats, sensors...), but gives no device type IDs, so there is no way to check a design against it before building. I would like to design to the list rather than discover at pairing time that Home will not create my accessory. A related composition question: my controller is a single accessory with seven independently controlled valve endpoints, and endpoints exist only for valves the installer has enabled. When a valve is disabled and its endpoint disappears, Home keeps showing it until the accessory is removed and re-added. Is there a supported way to make Home re-read a device's composition in place - and for seven valves, does Apple prefer one accessory with seven endpoints, or a Bridge (0x000E) exposing seven accessories? Setup: Matter over Wi-Fi (2.4 GHz), esp-matter / connectedhomeip, test VID 0xFFF1 during development. iOS 17 and 18, iPhone 12, Home hub present. Happy to provide the full endpoint and cluster composition or logs if useful.

Hi everyone, I recently submitted a request for the CarPlay Video App entitlement (com.apple.developer.carplay-video) via Apple's CarPlay entitlement request form. I submitted the request about a week ago, but I haven't received any update yet — no approval, rejection, or request for additional information. About the app: It is a video player designed for user-provided M3U/M3U8 playlists and locally imported media files. The app does not host, provide, or stream any built-in content itself. It follows Apple's CarPlay Video APIs and is intended to support video playback only when the vehicle permits video playback, such as when parked. I've noticed recent discussions from developers who already hold the CarPlay Video entitlement, but details regarding the review timeline seem quite limited. For developers who have successfully obtained the CarPlay Video entitlement: Approximately how long did it take from submitting the request form to receiving the entitlement decision? Did Apple reach out for additional details or clarification during the review process? Did you need an active TestFlight build or App Store submission prior to receiving the entitlement? Is there any dashboard or portal to track the status of a CarPlay entitlement request, or is email the only channel? Any insights from your experience would be greatly appreciated! Thanks!

My macOS app Find Any File contains another app inside its Resources folder. It's a background-only app that checks if the user presses a hotkey, in which case it launches my app. Since macOS 27, when the hotkey app is running, it appears in the Dock with a "Running in Background" subtitle. That's totally not wanted. How do I make it not appear in the Dock? I've got both "LSBackgroundOnly" and "LSUIElement" set to true in the Info.plist, to no avail.

We're experiencing an issue where the CarPlay Simulator (from Apple Developer Additional Tools) stopped connecting to our iPhones as of March 4th, 2025. The simulator gets stuck indefinitely on "Connecting to phone" and never completes the pairing. Environment App: Oracle Field Service iOS app (with CarPlay support) Tool: CarPlay Simulator from Apple Developer Additional Tools (developer.apple.com/download/all/) Issue start date: Wednesday, March 4th, 2025 Tested on: Multiple Mac machines, multiple iPhones Multiple CarPlay Simulator versions tested What's happening The CarPlay Simulator launches but displays "Connecting to phone" indefinitely. It was working correctly prior to March 4th with no changes on our end. What still works CarPlay functions correctly when the same iPhone is connected to a real car, confirming the issue is specific to the simulator. Troubleshooting steps already attempted Reset permissions and re-added the simulator Forgot the simulator and re-paired it Changed the USB cable Tested on multiple Mac machines Tested on multiple iPhones Tried multiple versions of the CarPlay Simulator Confirmed no VPN is in use Confirmed with IT, no OS updates or enterprise restrictions were applied Questions Has anyone else experienced this since March 4th? Was there a change in CarPlay Simulator behavior or a requirement on the Apple side (certificate, entitlement, protocol) around that date? Is there a known workaround or fix?

I see different storefronts in StoreKit product queries and Apple’s purchase sheet when testing through TestFlight. Xcode-installed builds work normally. iPhone — iOS 26.6 (23G71), US Media & Purchases account Both StoreKit 1 and StoreKit 2 return CHN/CNY. The app displays CNY 128 for a non-consumable, but Apple’s sandbox purchase sheet shows USD 29.99 for the same product. This reproduces in a standalone 177-line Swift sample using Product.displayPrice directly, with no third-party dependencies, currency conversion, or local .storekit configuration. Reloading products and signing out of the sandbox account did not resolve it. Mac Catalyst — macOS 26.3 (25D125), China purchase account The original TestFlight app returns USA/USD. Purchasing shows “Account Not In This Store” and asks to switch to China, although the purchase account is already set to China. The Mac symptom has not yet been verified in the standalone sample. Reproduction on the affected iPhone: install via TestFlight, load products and log Storefront.current plus the SK1 storefront, open the purchase sheet for the same product, then compare currencies. No completed purchase is needed. Built with Xcode 26.1 (17B55). Has anyone found a workaround for this TestFlight-only mismatch? Should the app handle storefront updates differently, and which additional diagnostics would help distinguish a device/account-session issue from a StoreKit service issue? Feedback: FB24873070. A focused sample and diagnostic evidence are prepared for Apple Developer Technical Support. Reproduction on other devices/accounts is not yet confirmed.

Hello, We are currently seeing errors when validating receipts for every auto-renewable subscription purchased through both StoreKit 1 and StoreKit 2. Details below. Case 1 — StoreKit 1 Calling https://buy.itunes.apple.com/verifyReceipt with the subscription receipt returns: "status": 21006, "expiration_intent": "5" Case 2 — StoreKit 2 Calling https://api.storekit.itunes.apple.com/inApps/v1/subscriptions and reading the most recent transaction (LastTransactionsItem) returns status 3. Within JWSRenewalInfoDecodedPayload: autoRenewStatus = 1, expirationIntent = 5 Timeline We believe renewals stopped processing for essentially all auto-renewing subscribers of our app as of 2026-09-18 09:30 KST (UTC+9). After resolving an agreement/licensing issue on our side, new purchases and some receipt validations recovered as of 2026-09-21 11:49 KST. However, most existing receipts still return expirationIntent = 5 when we query receipt validation or subscription status. Questions Is any action required on our side — a server-side change, a configuration change in App Store Connect, or a further review of our agreements? Now that the agreement issue is resolved, when are the renewals that were left pending during the outage expected to be processed? Any guidance would be appreciated. Thank you.

As part of the OpenJDK testing we run several regression tests, including for Java SE networking APIs. These APIs ultimately end up calling BSD socket functions. On macos, starting macos 26, including on recent 26.2 version, we have started seeing some unexplained but consistent exception from one of these BSD socket APIs. We receive a "ENOBUFS" errno (No buffer space available) when trying to construct a socket(). These exact same tests continue to pass on many other older versions of macos (including 15.7.x). After looking into this more, we have been able to narrow this down to a very trivial C code which is as follows (also attached): #include <stdio.h> #include <sys/socket.h> #include <string.h> #include <unistd.h> #include <sys/errno.h> static int create_socket(const int attempt_number) { const int fd = socket(AF_INET6, SOCK_STREAM, 0); if (fd < 0) { fprintf(stderr, "socket creation failed on attempt %d," " due to: %s\n", attempt_number, strerror(errno)); return fd; } return fd; } int main() { const unsigned int num_times = 250000; for (unsigned int i = 1; i <= num_times; i++) { const int fd = create_socket(i); if (fd < 0) { return -1; } close(fd); } fprintf(stderr, "successfully created and closed %d sockets\n", num_times); } The code very trivially creates a socket() and close()s it. It does this repeatedly in a loop for a certain number of iterations. Compiling this as: clang sockbufspaceerr.c -o sockbufspaceerr.o and running it as: ./sockbufspaceerr.o consistently generates an error as follows on macos 26.x: socket creation failed on attempt 160995, due to: No buffer space available The iteration number on which the socket() creation fails varies, but the issue does reproduce. Running the same on older versions of macos doesn't reproduce the issue and the program terminates normally after those many iterations. Looking at the xnu source that is made available for each macos release here https://opensource.apple.com/releases/, I see that for macos 26.x there have been changes in this kernel code and there appears to be some kind of memory accountability code introduced in this code path. However, looking at the reproducer/application code in question, I believe it uses the right set of functions to both create as well as release the resources, so I can't see why this should cause the above error in macos 26.x. Does this look like some issue that needs attention in the macos kernel and should I report it through feedback assitant tool?

I am developing an iOS application with a Location Push Service Extension and am trying to provide managed app configuration to the extension using Apple's ManagedAppConfigurationProvider and Declarative Device Management (DDM). The same managed configuration works correctly in the containing application, but the exact same API fails when called from the Location Push Service Extension. Environment: iOS: 26.2.1 Xcode: 16.4 Extension type: Location Push Service Extension The extension has the following entitlement in both the signed extension and provisioning profile: com.apple.developer.location.push The extension is configured through DDM using ExtensionConfigs: "ExtensionConfigs": { "bundleid (teamid)": { "DataAssetReference": "xxxxxxx" } } The Data Asset is successfully compiled by the MDM server and contains the managed configuration values. The device reports the following DDM status: "config-state": { "app-config-state": { "state": "valid" }, "extension-config-state": { "bundleidofextension": { "state": "unknown" } } } The main application can successfully retrieve the configuration using: let provider = ManagedAppConfigurationProvider() Task { for await configuration in await provider.configurations( ModelManagedAppConfiguration.self ) { print("APP CONFIG = (String(describing: configuration))") } } The same code and the same configuration type are used inside the Location Push Service Extension. Inside the extension, the provider is created successfully: LOCATION EXTENSION: creating ManagedAppConfigurationProvider LOCATION EXTENSION: provider created LOCATION EXTENSION: requesting configurations However, the request fails with: Failed to connect to managedappsd with error Error Domain=NSCocoaErrorDomain Code=4099 "The connection to service named com.apple.devicemanagementclient.managedappsd was invalidated from this process." Failed to fetch managed app configuration. Returning nil. Error: XPC connection failed with error Optional("Couldn’t communicate with a helper application.") Failed to determine managed app configuration changed notification name. Unable to register for notifications. Failed to report configuration error state. Error: XPC connection failed with error Optional("Couldn’t communicate with a helper application.") LOCATION EXTENSION: CONFIG = nil The important observation is that the configuration works from the containing application but fails from the Location Push Service Extension before the configuration reaches the Decodable configuration type. I have also verified: The extension Bundle ID matches the ExtensionConfigs entry. The Team ID matches. com.apple.developer.location.push is present in the signed extension. com.apple.developer.location.push is also present in the provisioning profile. The DDM Data Asset is successfully compiled. The containing application's managed configuration state is valid. The same ManagedAppConfigurationProvider code works in the containing application. According to Apple's documentation, ManagedAppConfigurationProvider provides configurations for a managed app or extension, and ExtensionConfigs is the DDM mechanism for configuring extensions. My question is: Is ManagedAppConfigurationProvider fully supported from a Location Push Service Extension? If it is supported, what could cause managedappsd to reject/invalidate the XPC connection specifically when the request originates from a Location Push Service Extension? Could there be an additional entitlement, extension-specific configuration, or system restriction required for ManagedAppConfigurationProvider to communicate with managedappsd from this type of extension? Any guidance on how to further diagnose the NSCocoaErrorDomain Code=4099 / "Couldn’t communicate with a helper application" error would be appreciated.

I have trouble with reading a file from an App Group with my System Network Extension. The app group container is found successfully. However the file read returns empty. In the app itself the same code runs fine and returns a string array of items found in the file. Code: func readFile() - [String] {         var jsonResult: [String] = []         guard let containerURL = FileManager.default.containerURL(forSecurityApplicationGroupIdentifier: AppConstants.groupID) else {             fatalError()         }         let fileURL = containerURL.appendingPathComponent("file.json")         if let data = try? NSData(contentsOfFile: fileURL.path, options: .mappedIfSafe) as Data {             if let json = try? JSONSerialization.jsonObject(with: data, options: .fragmentsAllowed) {                 jsonResult = json as! [String]             }         }         os_log("jsonResult: %{public}@", jsonResult)         return jsonResult     } Log: default 09:42:19.486793+0200 app-network-extension container_create_or_lookup_app_group_path_by_app_group_ identifier: success default 09:42:20.105792+0200 app-network-extension jsonResult: ( ) Edit, after more digging: fileURL is different! App: file:///Users/me/Library/Group%20Containers/ SysExt: file:///private/var/root/Library/Group%20Containers/

Hello, I am an individual developer enrolled in the paid Apple Developer Program, developing a native iOS calendar app that has not yet been released on the App Store. I would like to apply for iCloud Calendar access through Apple Account authorization, without requiring users to generate app-specific passwords. In this forum thread, an Apple DTS engineer recommended the iCloud OAuth2 interest form. I can access the form, but both “App Name” and “App Store URL” are required. Could someone clarify the correct process for an unreleased app? Can an individual developer submit an application before the app is published on the App Store? For “App Name,” may I enter the app’s current working name, or must it match an existing App Store Connect record? For “App Store URL,” what should I enter when no public App Store page exists? Would a URL based on an unpublished App Store Connect record’s numeric Apple ID be accepted, or is there an alternative submission process? I contacted Apple Developer Program Support, but they explained that their team handles developer account matters and referred me to technical support and the forums. If another team handles these application requirements, could you please direct me to the appropriate contact? Thank you for your guidance.

Apple's app-specific password support article says: "For supported third-party apps that access your iCloud Mail, Calendar, and Contacts, you can authorize the app using your Apple Account instead of using an app-specific password." I can't find any documentation about (1) what makes an app "supported," (2) how to apply or qualify, or (3) the technical mechanics — Sign in with Apple, OAuth scopes, MDM, etc. I'm building an iOS app (already approved for Gmail with the gmail.modify scope and CASA-assessed) that monitors a user's mailbox for scam emails with their explicit consent. I'd love to offer the same to iCloud Mail users without requiring the manual app-specific password flow, if there's a Sign in with Apple-style alternative available. Has anyone had success applying for this, or can an Apple engineer point to additional documentation? Thanks!

Hello, I am tracking a severe local networking regression on macOS Golden Gate 27.2 Developer Beta (build 26B5086k) running on MacBook Pro M4 Pro hardware. Despite negotiating a strong physical Wi-Fi connection with high PHY rates (1200+ Mbps) and excellent RSSI, actual throughput collapses dramatically and local gateway latency spikes uncontrollably whenever AWDL and AirDrop discovery are actively processing. Key Diagnostic Metrics Observed AWDL Manually Disabled: Executing sudo ifconfig awdl0 down completely drops packet loss to 0%, stabilizes gateway latency entirely, and restores baseline throughput. AirDrop Turned Off (AWDL Active): Disabling AirDrop via System Settings while keeping AWDL active stops the catastrophic latency spikes. This strongly suggests the trigger is linked directly to AirDrop's continuous background discovery/scanning activity rather than basic AWDL link states. Environment Isolation Performed Safe Mode: The issue persists cleanly while booted into macOS Safe Mode, ruling out third-party launch kexts, background daemons, or custom VPN software. Cross-AP Testing: The behavior follows the Mac across completely different access points, occurring on a dedicated Wi-Fi 7 home environment (tested across 5GHz and 6GHz channels) as well as an iPhone Personal Hotspot over cellular. Control Device: Same-location control testing with an iPhone shows perfect gigabit-class speeds, confirming the RF environment and network backhaul are perfectly healthy. I have already submitted a comprehensive sysdiagnose archive and wireless diagnostic log package directly to Apple. Feedback ID: FB24842970 Curious if anyone else with an M4 Pro on this build is seeing similar behavior. If this is happening on your end too, it might be worth submitting a bug report and referencing FB24842970 so Apple can group our logs together and look into a patch.

I develop a tool on macOS which is composed of an UI app to manage the main app settings, and an Agent that runs in background doing some tasks ? (Running the agent is optional, can be launched from the UI app, and can be launched by macOS at startup with SMAppService. ) Agent has the LSUIElement flag set, and only shows a Menu Extra (or whatever it now named), and sometimes some notifications. The whole App package is bundled this way MainAppUI.app/Contents/Library/LoginItems/AppAgent.app (for SMAppService to work) This has been working correctly for years Now on macOS 27 beta, once I quit the UI App, having launched the Agent, the Dock reports the UI App is still running in background (with the grey dot) . But only the Agent is running, not the UI app process. Moreover, System Settings->Background apps reports both the UI app AND the Agent as both requesting to run in background. I would have expected only the Agent being listed in System Settings, and nothing appearing in the Dock. Is this a bug in the OS beta , showing the top-level container bundle as the app running in background instead of the executable direct container ? Or maybe it's on me and I should bundle my app differently ? (I cannot "reverse" the bundle and put the Agent as the main app, with UI "inside", as double clicking the main app should launch the UI App , not the Agent. ) BTW, filed FB23203848 for the same subject. thanks for any direction

The documentation is pretty much blank. The same thing applies to the root NetworkProtocolOptions protocol. What are ContentType, LegacyMessage, BelowProtocol, Metadata, and ProtocolStorage? I can't determine if I should use these or not.

Hello! Users of my app observed behaviour that some apps stopped working after update to 15.7.8 via Beta channel with transparent proxy network extension on. The app receives Protocol not available error, and I see setsockopt SO_FLOW_DIVERT_TOKEN failed [42: Protocol not available] error in Console. To reproduce, create two rules in basic NETransparentProxyProvider: [[NENetworkRule alloc] initWithDestinationNetwork:nil prefix:0 protocol:NENetworkRuleProtocolTCP], [[NENetworkRule alloc] initWithDestinationNetwork:nil prefix:0 protocol:NENetworkRuleProtocolUDP], You may even return NO in handleNewFlow, it does not matter. After that, Safari won't open some sites, and Weather app will work unreliably. Do anyone knows any workaround for this problem? I've also create a relevant FB23788740.

Summary On macOS 26.6.2 (25G83) (Tahoe), Chrome fails to load pages hosted on private/local IP addresses (e.g. http://192.168.0.43/, a home AV receiver's web setup page) with ERR_ADDRESS_UNREACHABLE, while Safari loads the identical URL without issue on the same Mac, same network. ping to the target IP succeeds normally. System Settings > Privacy & Security > Local Network shows "Allow" for Chrome — but this is not what's actually being enforced. Traced the root cause to nesessionmanager stuck in an infinite retry loop when attempting to install/update NetworkExtension path-rule policies. Because the daemon never completes a successful policy install, nehelper (the actual enforcement point) continues serving a stale cached "denied" decision indefinitely, regardless of what the Settings UI shows or how many times the toggle is flipped. Key evidence Chrome netlog (chrome://net-export/) shows a genuine TCP connect attempt (not an early permission rejection): text TCP_CONNECT_ATTEMPT --> address = "192.168.0.43:80" -TCP_CONNECT_ATTEMPT --> os_error = 65 -TCP_CONNECT --> net_error = -109 (ERR_ADDRESS_UNREACHABLE) os_error = 65 is BSD EHOSTUNREACH, returned by the kernel at the connect() syscall. Unified log (log stream --predicate 'subsystem == "com.apple.networkextension"') shows the actual enforcement decision: text nehelper: UUID cache hit for com.google.Chrome nehelper: Local network denied by preference for Google Chrome (com.google.Chrome) This reproduced identically across multiple attempts, minutes apart, and survived sudo pkill -f nehelper — confirming the decision is persisted, not just an in-memory cache. While toggling the Local Network switch in System Settings, expecting a pathRules dump, the log instead showed: text NESMPathControllerSession[...]: No UUIDs in the cache for PathRuleDefaultNonSystemIdentifier, populating the cache from the path rules NESMPathControllerSession[...]: Will reinstall policies after 2000 milliseconds, retry 1 NESMPathControllerSession[...]: Will reinstall policies after 2000 milliseconds, retry 2 NESMPathControllerSession[...]: Will reinstall policies after 2000 milliseconds, retry 3 NESMPathControllerSession[...]: Will reinstall policies after 2000 milliseconds, retry 4 NESMPathControllerSession[...]: Will reinstall policies after 2000 milliseconds, retry 5 The retry counter kept incrementing with no observed successful completion, meaning any change made via the System Settings toggle can never actually propagate to nehelper. Also confirmed Local Network privacy is not TCC-backed at all: text $ sudo tccutil reset LocalNetwork tccutil: Failed to reset LocalNetwork $ sudo tccutil reset LocalNetwork com.google.Chrome tccutil: Failed to reset LocalNetwork approval status for com.google.Chrome Both fail outright rather than erroring on bad usage, confirming this permission lives entirely in the NetworkExtension path-rule system, with no supported reset command. What did not fix it Toggling the Settings UI switch off/on sudo tccutil reset SystemPolicyNetworkVolumes (wrong TCC service — doesn't apply here) sudo tccutil reset LocalNetwork (fails, see above) Full clean reinstall of Chrome, including all Application Support/Caches/Preferences Safe Mode boot sudo pkill -f nehelper Full normal system restart Launching Chrome with --no-sandbox (rules out Chromium's own internal sandbox as a factor — this is a system-level enforcement, not a Chromium-side block) Working fix Requires temporarily disabling SIP: text In macOS Recovery (csrutil only works from Recovery, not Safe Mode): csrutil disable Back in normal macOS: sudo rm /Library/Preferences/com.apple.networkextension.plist Back in Recovery: csrutil enable Restart normally. nesessionmanager rebuilds the NetworkExtension policy state from scratch on next boot. System Settings > Privacy & Security > Local Network shows a clean list afterward (also clears the separate, previously-known bug where every Chrome auto-update was creating a new duplicate entry in that list rather than updating the existing one). Chrome's next navigation attempt to a local IP correctly triggers a fresh permission prompt, and functions normally once granted. Why this matters Apple's own TN3179 states there's no supported way to reset an app's Local Network privilege to "undetermined." This bug compounds that: once nesessionmanager gets stuck in this retry loop, there is no path back to a working state short of disabling SIP and manually deleting a system preference file. The Settings UI also actively misrepresents the true enforcement state (shows "Allow" while nehelper enforces "denied") with no indication to the user that anything is wrong. This is likely not Chrome-specific — any app relying on Local Network access (smart-home apps, casting/streaming apps, IoT config tools) would hit the identical wall once a Mac's nesessionmanager enters this state. Also filed via Feedback Assistant. Happy to share the full decoded netlog trace if useful — didn't attach it here to keep this post scannable, but can paste the additional detail on request.

I have a shell script that moves files from one external drive to another. When I do the mv command from the terminal (which is iTerm2), I can do it. When I run the script from the terminal command prompt mv complains : rename, no such file or directory. I have given mv the full disk access permission iTerm2 has it too.

We are attempting to integrate the Apple Pay service into our website and have successfully verified our domain with Apple manually. However, we consistently receive an 'ApplePay reverify failed' email a month before the expiration time. Upon checking, we updated the SSL certificate for the domain before receiving the email, and the link still works fine in the browser. We would greatly appreciate any feedback from someone who can help us with this issue.

一部のiPadで電源が0%になるとどの充電器でも1%までおおよそ9時間もかかります

Hello, I submitted a mass subscription renewal date extension request using the App Store Server API on September 9, 2026. The request was accepted successfully. However, when I check the request using getStatusOfSubscriptionRenewalDateExtensions, the status continues to return: complete: false As of September 20, the request has remained incomplete for 11 days. Request details: Extension: 1 day Reason: temporary service interruption Environment: Production The documentation states that a mass renewal date extension may take hours or even days to complete, but I have not been able to find guidance for a request that remains incomplete this long. Only three subscribers were affected by the service interruption, and I have their originalTransactionId values. I am considering using the individual subscription renewal date extension API instead. My questions are: Is it expected for a mass renewal date extension request to remain complete: false for 11 days? Could this mass request still complete at a later date? Is there any way to cancel or determine whether this mass request is stuck? If I extend the three affected subscriptions individually now, is there a risk that the pending mass request could later complete and extend them a second time? I would like to compensate the affected subscribers as soon as possible while avoiding duplicate extensions. Thank you for any guidance.