Module Showcase configuration fields can all turn invalid when the license-management API rejects or mishandles the edit request for an unapproved module. Re-entering values in the editor will not repair a server-side fault. Separate approved from unapproved modules, test a second client against the same records, then retest after the API hotfix.
Skip the fixes that only touch the editor
Start by avoiding changes that add risk without testing the failing layer.
| Quick fix | Why it fails here | Use it only to |
|---|---|---|
| Re-enter every field | All fields entering the error state together points to a failed configuration transaction, not independent typing errors. | Correct a field after the API identifies a specific validation failure. |
| Reload the page repeatedly | A reload creates another request to the same API. It cannot remove a defect in that service. | Discard stale browser state after the service has been repaired. |
| Switch from the web editor to the Vision-based Showcase API project | Both clients depend on the affected API path. Changing the front end does not bypass the common service. | Prove whether the fault follows the record across clients. |
| Delete and recreate the module entry | This changes production data before the failing layer has been isolated and may leave the replacement record subject to the same fault. | Recover only when official support directs the data-repair sequence. |
Do not treat a page full of red fields as proof that every stored value is bad. Capture the condition before editing anything: module approval state, affected operation, visible field errors, time of the attempt, and whether known-approved modules remain editable.
Split the test by module approval state
The decisive comparison is approved versus unapproved modules. Approved modules edited normally while unapproved modules produced the all-fields error. That boundary narrows the fault to processing associated with unapproved records rather than a general outage, browser problem, or universal schema change.
- Select one known-approved module and open its configuration without changing values.
- Select one unapproved module and perform the same operation.
- Record whether the complete field set enters the error state only for the unapproved record.
- Repeat the comparison through the other available client, such as the Vision-based Showcase API project.
If approved and unapproved modules now fail in both clients, stop using this incident pattern as the diagnosis. Check the current service status and capture the API response because the scope has expanded beyond the approval-state defect.
Locate the fault at the shared API boundary
A configuration editor normally loads a record, maps returned properties into fields, applies validation, and sends an update request. A failure in a shared API can make every mapped field appear invalid even when the stored values were previously accepted. The visible field errors are then a downstream symptom of a rejected, malformed, or unsuccessfully processed transaction.
The cross-client test separates the layers:
| Observation | Most useful conclusion | Next check |
|---|---|---|
| One client fails and another succeeds on the same module | Investigate client state, field mapping, or client-specific validation. | Compare the requests and responses from both clients. |
| Both clients fail only on unapproved modules | The shared API path or approval-state handling is the primary fault domain. | Preserve response details and wait for or confirm the server correction. |
| Approved and unapproved modules both fail | The failure is broader than the documented defect. | Check authentication, service availability, and the returned error payload. |
| The editor loads, but one field alone fails | Treat it as field-level validation rather than this all-fields incident. | Review that field's value, type, and validation message. |
Use browser developer diagnostics or the client log to capture the request result if those tools are already available. Record the HTTP status, response body, request time, and affected module state. Do not edit credentials, tokens, or unrelated network settings merely because the request passed through an API.
Restore service after the API hotfix
The working correction was an API hotfix. No module-side field rewrite was required. Once the fix has been deployed, clear only the transient client state and repeat the controlled test.
- Save screenshots or logs from the failed attempt before refreshing the client.
- Close the affected edit panel so it cannot submit stale values.
- Reload the license-management client or reopen the Vision-based client session.
- Open the same unapproved module that previously failed.
- Change one low-risk configuration value, submit it, and reopen the record.
- Confirm that the saved value returns correctly before making the full required edit.
If the panel was left open during the deployment, reload it before judging the hotfix. Cached form state can preserve old validation markers even though new API calls now succeed. Get the edit path running first; handle any unrelated cleanup as a separate change.
Verify the repair across records and clients
One successful page load is not enough. Verify reading, writing, and persistence because each operation can exercise a different API path.
| Verification | Pass condition |
|---|---|
| Open an approved module | Existing fields load without a page-wide error. |
| Open an unapproved module | Existing fields load without the former all-fields error. |
| Submit one controlled edit | The client reports success and does not mark every field invalid. |
| Reopen the edited module | The changed value persists and other values remain intact. |
| Test the second client | The same unapproved record can be loaded or edited through the shared API consumer. |
Use more than one unapproved record if available. A single repaired record could hide record-specific corruption, while repeated success across unapproved records confirms that approval-state handling has recovered.
Keep the next incident contained
Preserve the approval-state comparison as a standard first check. It is faster and safer than rewriting configuration fields. When every field fails at once, test the transaction boundary before treating the fields as separate faults.
- Do not approve a module solely to bypass an edit failure; that changes workflow state and masks the diagnostic boundary.
- Do not bulk-edit affected records while the API response remains abnormal.
- Do not delete records until their identifiers, current configuration, and recovery path have been captured.
- Do not report only the screenshot. Include approval state, client used, operation attempted, timestamp, and response details.
If the failure returns after a confirmed hotfix, compare a known-approved record and a known-unapproved record again. That distinguishes recurrence of the same approval-state defect from a wider service problem.
FAQ
What happens if only unapproved Module Showcase modules fail?
Treat approval state as the fault boundary. Test an approved and an unapproved record through both available clients; failure of only the unapproved records in both clients points to shared API handling rather than bad values in every field.
What happens if the web editor and Vision-based client both fail?
Both clients are reaching a common failing layer. Capture the API response and stop changing editor fields, because moving between front ends will not correct the server transaction.
What happens if fields still show errors after the hotfix?
Close and reload the edit panel, then test one approved and one unapproved module and verify a saved value by reopening the record. Stop here if both clients still fail or saved data does not persist; preserve the request time, response details, module approval state, and screenshots, then escalate through Inductive Automation's official support channel without deleting or recreating the module.