feat: Adding sample coded action apps

[Sandeepan-Ghosh-0312]

Added sample coded action apps

[claude]

Review findings

Seven inline comments posted across the four new sample apps:

Missing error handling (3 files)

• templateWithDoc, templateWithFileAttachment, templateWithStorageBucket — getTask().then(...) has no .catch(). Any rejection (auth failure, network error) is silently swallowed and the UI stays in its initial state with no feedback. templateWithDataFabric already uses the correct async/await + try/catch pattern; the other three should match it.

any type violations (4 instances in 2 files)

• templateWithStorageBucket/Form.tsx:55 — useState<any> → useState<string | null>
• templateWithStorageBucket/Form.tsx:93 — (b: any) annotation in .find() callback — drop it, the array element type is already inferred
• templateWithStorageBucket/Form.tsx:103-104 — (uriResponse as any).requiresAuth / .headers — if these fields exist on the API response they should be in the SDK return type for getReadUri; casting them away hides a type definition gap
• templateWithDataFabric/Form.tsx:94 — (e: any) in .find() — drop it
• templateWithDataFabric/Form.tsx:110 — result.items?.[0] as any — define a typed interface for the record shape instead

[claude]

Review findings

One new inline comment posted this run:

Missing error handling — templateWithImage/Form.tsx:40

codedActionApps.getTask().then(...) has no .catch(). Any rejection (auth failure, network error) is silently swallowed and the UI stays in its initial state with no user feedback. The other three templates (templateWithDoc, templateWithFileAttachment, templateWithStorageBucket) have the same open issue from the prior review. templateWithDataFabric already uses the correct async/await + try/catch pattern and should be used as the reference.

[claude]

Review findings

Two new inline comments posted this run:

Missing response.ok check + no try/catch in handleDownload (2 files)

• templateWithStorageBucket/Form.tsx:149 — fetch(documentUrl) with no response.ok guard and no error handling. An expired signed URL (403/404) produces a corrupt blob; a network error throws an unhandled rejection from the click handler.
• templateWithFileAttachment/Form.tsx:141 — same issue.

Both should add if (!response.ok) throw new Error(...) after the fetch, and wrap the function body in try/catch to surface errors via showMessage.

The nine previously-raised threads (unhandled rejections on getTask(), any types, as any casts on uriResponse) remain open and unresolved.

[claude]

Review findings

Two new inline comments posted this run:

Missing error handling in handleDownload (2 files)

• templateWithFileAttachment/Form.tsx:133 — handleDownload is async but has no try/catch. If fetch(documentUrl) fails (expired signed URL, network error, non-2xx), the rejection is unhandled and the user gets no feedback.
• templateWithStorageBucket/Form.tsx:141 — same issue. Both files have solid error handling in loadDocument but the pattern wasn't carried over to handleDownload.

[claude]

Review findings (this run)

One new inline comment posted:

Missing error handling on completeTask / stuck isSubmitting state — templateWithDataFabric/Form.tsx:243

completeTask is called outside the try/catch that guards updateRecordById. If it throws, isSubmitting is never reset, permanently disabling the Approve/Reject buttons with no user feedback; and the rejection propagates as an unhandled promise from the click handlers. Additionally, setIsSubmitting(true) is only set inside the if (entityId && recordId) block, leaving the buttons unguarded against double-clicks when there is no DF record. The suggestion restructures to a single top-level try/catch/finally.

The eleven previously-raised threads remain open and unresolved.

[claude]

Review findings

Four new inline comments posted this run:

Unhandled completeTask errors in submit handlers (4 files)

handleApprove and handleReject call completeWith() which returns a Promise, but the handlers neither await it nor catch rejection. If completeTask fails (network error, auth expiry, task already completed), the error is silently swallowed and the user gets no feedback.

• templateWithDoc/Form.tsx:101-102
• templateWithImage/Form.tsx:92-93
• templateWithFileAttachment/Form.tsx:198-199
• templateWithStorageBucket/Form.tsx:208-209

templateWithDataFabric already uses the correct pattern (async handler + try/catch + showMessage). Each comment includes a one-click suggestion to apply the same fix.

The 11 previously-raised threads (missing .catch() on getTask(), any types, as any casts, missing response.ok checks in handleDownload) remain open and unresolved.

[claude]

Review findings

One new inline comment posted this run:

Dead pageRendering state (templateWithDoc/Form.tsx:46)

pageRendering is initialized to false and is only ever reset to false inside onRenderSuccess/onRenderError — setPageRendering(true) is never called, so the pdf-page--rendering CSS class is never applied. Fix: call setPageRendering(true) when navigation/zoom triggers a re-render, or remove the state and conditional class entirely. The same bug is present in the three other PDF-using samples (templateWithFileAttachment, templateWithStorageBucket, templateWithDataFabric).

The 13 previously-raised threads (unhandled rejections on getTask(), any type violations, as any casts on uriResponse, missing response.ok checks in handleDownload) remain open and unresolved.

[claude]

Review findings

One new inline comment posted this run:

OData filter injection — templateWithStorageBucket/Form.tsx:90

filter: name eq '${formData.loanDocumentStorageBucket}'`` interpolates the bucket name directly into an OData filter string without escaping. A name containing a single quote breaks the query; in an adapted version that uses user-controlled input this becomes a filter injection (analogous to SQL injection). The fix is to double any embedded single quotes (value.replace(/'/g, "''")) or to switch to a structured filter API. Suggested inline.

The 19 previously-raised threads (unhandled rejections on getTask(), useState<any>, (b: any) / as any casts, missing response.ok checks in handleDownload, unhandled completeTask errors in submit handlers, dead pageRendering state) remain open and unresolved.

[claude]

Review findings

One new inline comment posted this run:

Missing isSubmitting guard — templateWithStorageBucket/Form.tsx:262 (and templateWithFileAttachment/Form.tsx:252)

isFormValid in both files does not include an !isSubmitting check. A rapid double-click on Approve or Reject sends two concurrent completeTask calls; the second will likely throw on an already-completed task, showing a confusing error message to the user even though the first call succeeded. templateWithDataFabric already uses the correct pattern (isSubmitting state + try/finally in handlers). The inline comment includes a suggestion for the fix.

The 19 previously-raised threads have all been actioned in the code (most issues were fixed; the OData filter injection thread remains open).

[claude]

✅ No issues found. Checked for bugs and CLAUDE.md compliance.

[claude]

✅ No issues found. Checked for bugs and CLAUDE.md compliance.

[claude]

✅ No issues found. Checked for bugs and CLAUDE.md compliance.

[claude]

✅ No issues found. Checked for bugs and CLAUDE.md compliance.

[claude]

Review findings

Two new inline comments posted this run:

Premature blob URL revocation in loadDocument effect cleanup (2 files)

In both action-app-with-file-attachment-document/Form.tsx:140-146 and action-app-with-storage-bucket-document/Form.tsx:151-157, the useEffect cleanup revokes blobUrlRef.current. When loading succeeds and hasLoadedDocument transitions to true, React re-runs the effect, firing the previous cleanup first — which revokes the blob URL before react-pdf has reliably fetched it. Race condition: PDF viewer intermittently fails to load.

action-app-with-data-fabric-entity/Form.tsx already uses the correct pattern: effect cleanup is only cancelled = true, and blob URL revocation lives in a separate unmount-only useEffect.

[claude]

✅ No issues found. Checked for bugs and CLAUDE.md compliance.

[claude]

✅ No issues found. Checked for bugs and CLAUDE.md compliance.

[claude]

✅ No issues found. Checked for bugs and CLAUDE.md compliance.

[claude]

✅ No issues found. Checked for bugs and CLAUDE.md compliance.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud