Real issues from implementations and a Redwood rollout

 Part of my Oracle Fusion HCM Fix of the Day series: real issues from implementations and a Redwood rollout I led without a Systems Integrator, and how I fixed each one.

This is Fix #2. Start from Fix #1 to follow the series in order.

Quarterly patches are part of life on Oracle Fusion. Most of the time they land quietly. This one did not. After the 26A patch, I opened a Visual Builder Studio workspace to continue a Redwood page extension, and the Page Designer canvas simply would not render. This post covers what I saw, what caused it, and the fix that worked.

The symptom

The workspace opened. The project files were all there. I could browse the page structure and open the source view. But the design canvas in Page Designer stayed blank or kept spinning. I could not see or select any components on the page, so I could not make visual changes at all.

Nothing in my extension had changed. The same workspace had worked fine before the patch. That was the first clue that the problem was not in my code.

Why it happens

A VB Studio workspace is not just a copy of your source files. It also holds metadata about the runtime it is built against. That includes the Runtime Dependency information, which tells the designer which version of the Fusion application components and Redwood libraries to load.

When Oracle applies a quarterly patch, the underlying Fusion runtime moves to a new version. An older workspace can keep pointing at the old runtime details. The designer then tries to load components that no longer match what the environment is serving. The result is a canvas that cannot draw the page.

In my case, the Runtime Dependency metadata in the workspace was stale after 26A. The project itself was fine. The workspace was the problem.

How I fixed it

1. I made sure every change I cared about was committed and pushed to the project's Git repository. This step matters. Deleting a workspace removes anything that only lives there.
2. I checked the repository to confirm the latest commit had my recent changes.
3. I deleted the affected workspace from VB Studio.
4. I created a fresh workspace from the same project and branch.
5. I opened the extension in the new workspace and let it load against the current runtime.
6. I opened the Redwood page in Page Designer. The canvas rendered normally, and the components were selectable again.
7. I previewed the page and ran a quick test of the extension to confirm nothing else had shifted with the patch.

The whole fix took less time than I had already spent trying to refresh the browser and clear the cache. Those steps did not help, because the stale data was inside the workspace, not in the browser.

How to avoid it next time

• Commit and push your work before every quarterly patch window. A clean repository makes recreating a workspace safe and quick.
• Treat workspaces as disposable. The project and repository are the source of truth.
• After each patch, open your key Redwood extensions in Page Designer early, before anyone needs an urgent change.
• If the canvas fails after a patch, check the workspace before you start debugging your own code.
• Read the quarterly update notes for VB Studio and Redwood changes, so you know what moved underneath you.

Key takeaway

When the VB Studio canvas breaks right after a quarterly patch, suspect stale workspace metadata first. Push your changes, delete the workspace, and recreate it from the project.

Next in the series: Redwood payslip generation fails with "mainTemplPath is null", and how a catalog path mismatch caused it.

More at meera2k10.github.io/enterprise-ai