fix: result from iiko

[hmbanan666]

---

Summary by cubic

Parse the iiko integration response to JSON so sendToIntegration returns structured data instead of a raw Response. This fixes incorrect result handling in the Tilda Fila endpoint.

^{Written for commit 5f3f0cd. Summary will update automatically on new commits.}

Summary by CodeRabbit

• Bug Fixes
  • Fixed token handling in the Tilda integration: the access token is now returned and consumed as a plain string.
  • Added defensive checks and explicit error logging/500 response when token is missing.
  • Updated downstream integration calls to use the string token so deliveries requests process correctly.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Caution

Review failed

The pull request is closed.

Walkthrough

createAccessToken was changed to return a plain token string (Promise); sendToIntegration now treats the token as a string, adds a check to throw a 500 if the token is missing, and continues to call the deliveries/create API using that token.

Changes

Cohort / File(s)	Summary
Token handling & integration call apps/web-app/server/api/tilda/fila.post.ts	Changed createAccessToken() return type from { token: string, correlationId: string } to string. Updated sendToIntegration to extract/validate the string token (throw 500 if missing) and pass the token into the existing deliveries/create request; adjusted token usage accordingly.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

• Pay attention to the changed exported signature of createAccessToken() and any other callers in the codebase.
• Verify error handling/logging paths for missing token and downstream request behavior.

Possibly related PRs

• fix: result from iiko #266 — Modifies response handling in apps/web-app/server/api/tilda/fila.post.ts; likely touches the same functions (createAccessToken / sendToIntegration) and is directly related.

Poem

🐰 I nibble tokens from the loggy tree,
I bring back strings, not a JSON key,
A careful hop, a check for none,
Then off it goes — deliveries run! 🥕

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'fix: result from iiko' directly relates to the main change: parsing the JSON response from the iiko integration API call instead of returning the raw Response object.

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 2662455 and 5f3f0cd.

📒 Files selected for processing (1)

• apps/web-app/server/api/tilda/fila.post.ts (2 hunks)

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

apps/web-app/server/api/tilda/fila.post.ts (1)

152-160: Consider switching to await for clearer error handling and typing

Right now you return the fetch promise chain directly. That means:

• The local try/catch in sendToIntegration only handles errors up to createAccessToken; failures from fetch / res.json() are only caught by the outer event handler’s try/catch.
• The return type of sendToIntegration is effectively any, which makes it harder to rely on the IIKO response shape elsewhere.

You could make error handling and types clearer by using await and (optionally) typing the response:

async function sendToIntegration(data: TildaFilaBody) /* : Promise<unknown | IIKOCreateDeliveryResponse> */ {
  const logger = useLogger('api:tilda:fila')
  const { iiko } = useRuntimeConfig()

  try {
    const { token } = await createAccessToken()
    // ...build body as before...

    const res = await fetch(apiUrl, {
      method: 'POST',
      headers: {
        'Content-Type': 'application/json',
        Authorization: `Bearer ${token}`,
      },
      body: JSON.stringify(body),
    })

    const json = await res.json()
    return json
  } catch (error) {
    logger.error(error)
    // optionally: rethrow if you want caller to see integration failures
    // throw error
  }
}

This keeps all network/JSON errors within the same try/catch and makes the control flow easier to reason about, while preserving the new “parsed JSON” behavior.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between a32066c and 2662455.

📒 Files selected for processing (1)

• apps/web-app/server/api/tilda/fila.post.ts (1 hunks)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)

• GitHub Check: cubic · AI code reviewer
• GitHub Check: build

🔇 Additional comments (1)

apps/web-app/server/api/tilda/fila.post.ts (1)

152-160: Return type change to parsed JSON looks good

Returning await fetch(...).then((res) => res.json()) from sendToIntegration matches the PR goal: result in the handler is now the actual IIKO JSON payload rather than a Response object, so the log on Line 14 becomes much more informative. Since sendToIntegration is only used in this file and the caller only logs result, this behavior change is safe.

[cubic-dev-ai]

No issues found across 1 file

[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