check if functions from this converter can be async

[github-actions]

📝 Found in apps/meteor/app/apps/server/converters/visitors.ts#L7

Commit: 14d0718

[coderabbitai]

🔗 Related PRs

#41205 - chore: refactor apps converters to TypeScript with Zod codecs (2/2) [open]
#41400 - chore: refactor apps converters to TypeScript with Zod codecs (1/2) [open]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[mgstabrani]

I took a look at this converter to see whether its functions can/should be async.

Current state

The interface (packages/apps/src/converters/IAppVisitorsConverter.ts) already splits the methods into async and sync, and the implementation matches it:

• convertById, convertByToken, convertVisitor → already async. They do DB lookups (LivechatVisitors.findOne…) and call transformMappedData, which is itself async, so they need to be.
• convertAppVisitor → sync. It's the reverse direction (App → RC) and just assembles a plain object from fields already in memory. No DB, no await.

Can convertAppVisitor be made async?

It can, but there's no functional reason to — it does no asynchronous work. And it's currently called synchronously at four sites in apps/meteor/app/apps/server/bridges/livechat.ts (lines 61, 120, 146, 297), none of which await the result:

• sendMessage guest (L61)
• createRoom({ visitor }) (L120)
• closeRoom close data (L146)
• transfer(...) (L297)

If convertAppVisitor returned a Promise, all four would need an await added, otherwise they'd pass a pending Promise instead of the visitor object. Two of them (L61, L297) are also already flagged with #AppsEngineTypes type-mismatch TODOs.

Suggestion

The async/sync split looks correct as-is. I'd propose either:

1. Close/resolve the TODO noting convertAppVisitor stays sync by design (no async work), or
2. If uniform signatures across converters are preferred, make convertAppVisitor async and add await at the four livechat.ts call sites.

Happy to open a PR for either — could a maintainer confirm which direction is preferred before I start?