I am having a serious issue with the management of my shared component subscriptions and would kindly ask the Oracle APEX team to review it. If needed i can provide the details in my oracleapex.com workspace and application ID's where this can be reproduced.
Environment
- Oracle APEX 26.1.1, reproduced from scratch on oracleapex.com — no upgrade history, no legacy components.
- Also seen on a private Oracle DB 19c / APEX 26.1.2 instance at scale (one master subscribed by ~40 apps).
Reproduction (3 apps, built new)
- MASTER app: create a Component Group containing the app's Navigation Bar list plus one authorization scheme.
- SUBSCRIBER template app: subscribe that Component Group from MASTER.
- Create an APPLICATION COPY from the SUBSCIBER template app
- Create a Working Copy of APPLICATION COPY, change NOTHING, merge it back.
What I observe
(1) The subscription is "needs refresh" from the moment it is created. APEX_SUBSCRIBED_COMPONENTS shows the COMPONENT_GROUP, LIST and AUTHORIZATION as NEEDS_REFRESH immediately (subscriber version hash ≠ master version hash); only the THEME is UP_TO_DATE. I cannot get the group/list/auth subscription to UP_TO_DATE at all.
(2) Creating a Working Copy of the SUBSCRIBER modifies the MASTER. The MASTER's Component Group and List LAST_UPDATED_ON change to the exact instant the working copy is created (measured: 05:03:48 before → 05:20:20 immediately after; the subscriber's own components did not change — only the master moved). In a real workspace this flips every OTHER subscriber of that master to "needs refresh", so subscriptions can never all be current at once.
(3) In the Working Copy, the subscribed list's entries get brand-new IDs. Every LOCAL component in a working copy receives a fixed ID offset (wc id = source id + constant), which is how merge maps components back. The SUBSCRIBED list's entries instead get fresh, unrelated IDs:
- local Navigation Menu:
37983626881184023019 → 56978511940799139611 (offset +18994885059615116592, mergeable)
- subscribed Navigation Bar head: source
18991883619545017763, source+offset would be 37986768679160134355, but the working copy actually has 18994895696804116960 (fresh).
(4) Merging the UNCHANGED Working Copy back is therefore not a no-op. The merge preview reports "0 Changed, 3 Added, 3 Missing" on the subscribed list — the same three entries (static ids app-user, list_item, sign-out) each shown once as Added (wc fresh id) and once as Missing (source id). Because the "Added" entries reuse static ids that still exist in the target, executing the merge raises ORA-00001 on the list-entry unique constraint (as on my 27-entry production list). Non-subscribed lists in the same copy merge with zero differences.
Expected
- Creating/merging an UNCHANGED Working Copy should be a no-op and must not modify the master.
- A subscribed component's identity should be preserved in a Working Copy (same offset as local components) so the merge maps it cleanly.
Questions
- Is this known / expected in 26.1?
- Is there a supported way to use component subscriptions (specifically a Component Group containing a list) together with the Working Copy / merge workflow?