Client/Server: Initial session interactions by Zaid-Ajaj · Pull Request #574 · informedica/GenPRES

Zaid-Ajaj · 2026-09-07T16:02:48Z

Description

This PR contains the initial session interactions implementation between client and server. It scaffolds a skeleton for the launch sequence of GenPRES from an external application via the /session?launch={token}. Received on the client initially, it is transferred to the server from which the redeem token is derived and sent back to the client. Afterwards, the client uses the redeem token to acquire session information.

The idea is that subsequent operations on the client will carry a redeem token to validate who can do what and when.

The actual derivation, name and validation of the redeem token is stubbed out for now. As well as the functionality to retrieve the patient information.

When there is no launch token, the session is anonymous and continues to work the way it used to be; being able to parse the patient info still from the initial URL.

Finally, this PR fixes an issue in Feliz.Router where it never triggered UrlChanged because the dispatch function it acquires was not stable. This is now resolved (with a bit of help from Claude)

# Please enter a commit message to explain why this merge is necessary, # especially if it merges an updated upstream into a topic branch. # # Lines starting with '#' will be ignored, and an empty message aborts # the commit.

github-actions · 2026-09-07T16:05:39Z

Test Results

1 554 tests ±0 1 548 ✅ ±0 2m 25s ⏱️ +35s
16 suites ±0 6 💤 ±0
16 files ±0 0 ❌ ±0

Results for commit b970395. ± Comparison against base commit 0557a24.

This pull request removes 16 and adds 16 tests. Note that renamed tests count towards both.

GenCore.EnteralAccess ‑ 0 can create enteral access 
GenCore.EnteralAccess ‑ 1 can create enteral access duodenal
GenCore.EnteralAccess ‑ 2 can create enteral access oral
GenCore.EnteralAccess ‑ 3 can create enteral access oral
GenCore.EnteralAccess ‑ 4 can create enteral access anyenteral
GenCore.EnteralAccess ‑ 6 can create enteral access 
GenCore.EnteralAccess ‑ 7 can create enteral access anyenteral
GenCore.EnteralAccess ‑ 8 can create enteral access gastric
GenCore.EnteralAccess ‑ 9 can create enteral access 
GenCore.venousAccess ‑ 0 can create venous access central
…

GenCore.EnteralAccess ‑ 0 can create enteral access duodenal
GenCore.EnteralAccess ‑ 1 can create enteral access anyenteral
GenCore.EnteralAccess ‑ 2 can create enteral access duodenal
GenCore.EnteralAccess ‑ 3 can create enteral access anyenteral
GenCore.EnteralAccess ‑ 4 can create enteral access gastric
GenCore.EnteralAccess ‑ 6 can create enteral access gastric
GenCore.EnteralAccess ‑ 7 can create enteral access duodenal
GenCore.EnteralAccess ‑ 8 can create enteral access oral
GenCore.EnteralAccess ‑ 9 can create enteral access anyenteral
GenCore.venousAccess ‑ 0 can create venous access anyvenous
…

♻️ This comment has been updated with latest results.

greptile-apps · 2026-09-07T16:06:09Z

Confidence Score: 4/5

The PR does not yet appear safe to merge because delayed launch or redemption completions can still replace a newer active session.

Summary

Adds shared session token and content contracts plus server launch/redeem endpoints.
Adds client session parsing, asynchronous launch/redemption handling, and session identity display.
Introduces a patient-loading port and stub adapter for redeemed sessions.
Keeps anonymous patient URL parsing and dependent patient-state resets.
Uses a ref-backed router callback so navigation listeners invoke the latest callback.

Diagram

sequenceDiagram
    participant E as External application
    participant C as GenPRES client
    participant S as GenPRES server
    participant P as Patient port

    E->>C: "Open /session?launch={token}"
    C->>S: launchSession(launch token)
    S-->>C: redeem token
    C->>C: "Navigate to /session?redeem={token}"
    C->>S: redeemSession(redeem token)
    S->>P: loadPatientData(patient ID)
    P-->>S: Patient
    S-->>C: SessionContent
    C->>C: Display user and patient context

greptile-apps · 2026-09-07T16:06:12Z

+    let launchSession (env: AppEnv) (token: SessionLaunchToken) : Async<Result<SessionRedeemToken, string>> =
+        // TODO: implement proper session launch logic,
+        // which checks the validity of the token and returns a redeem token if valid, or an error if invalid.
+        let (SessionLaunchToken token) = token
+        async { return Ok(SessionRedeemToken "test-redeem-token") }
+
+    let redeemSession (env: AppEnv) (token: SessionRedeemToken) : Async<Result<SessionContent, string>> =
+        async {
+            let (SessionRedeemToken token) = token
+
+            if token = "demo-error" then


Session Tokens Are Unvalidated

These remotely exposed operations accept effectively arbitrary tokens. launchSession ignores the supplied launch token and always returns test-redeem-token, while redeemSession accepts every token except demo-error and returns session identity and patient content. Because the remoting API has no separate authentication gate, any remote caller can create and redeem a session without proving identity or permissions. These endpoints must fail closed until redeem tokens are validated, bound to a session, and protected against replay.

How this was verified: The public remoting API routes caller-supplied tokens directly to functions that issue a fixed token and return session content without an authentication check.

Knowledge Base Used:

GenPRES prescribing application

Prescribing API and composition

This is a stub, not the final production code. The real production code will follow: docs/scenarios/integration/GenPRES-MainEHR-Integration-V8.md

Understood. Since this is explicitly a scaffold and the token derivation/validation is deferred to docs/scenarios/integration/GenPRES-MainEHR-Integration-V8.md, I would treat this as a release-risk reminder rather than a defect in the intended production flow. The key constraint is that these stubs must not be exposed as production authentication: until the documented implementation lands, the endpoints should remain clearly non-production or fail closed.

greptile-apps · 2026-09-07T16:06:12Z

+            let state =
+                { state with
+                    SessionContext = SessionContext.Content(Resolved content)
+                    Patient = Some content.Patient
+                }
+
+            state, Cmd.none


Redeeming Leaves Stale Results

A successful redemption assigns content.Patient directly instead of using the existing UpdatePatient lifecycle. When the redeemed patient differs from the patient currently in state, the order context, order plan, nutrition plan, formulary, and parenteralia remain associated with the previous patient because none of them are reset or reloaded. This can display clinically stale results beside the newly redeemed patient.

Knowledge Base Used:

GenPRES prescribing application

Prescribing client workflows

This will be part of a different pathway. The existing pathway only is meant for anonymous use and will be separate from the pathway this applies to.

That distinction addresses the concern. If the redeemed-session flow always starts without the anonymous patient/order state, assigning content.Patient directly cannot leave anonymous results associated with it. The stale-state risk would only apply if a session could be redeemed after an existing patient had already been loaded in the same app instance. No change is needed for the separate pathways described here.

greptile-apps · 2026-09-07T16:06:12Z

+        | SessionContextMsg(SessionContextMsg.Launched(SessionRedeemToken token)) ->
+            state, Cmd.navigate ("session", [ "redeem", token ])


Stale Session Requests Win

Launch and redemption completions are not tied to the session request that is still current. If the user changes the URL or starts another session while an earlier request is delayed or awaiting the server, the older Launched result still navigates to its redeem URL and the older Redeemed result still overwrites the active session and patient. Carry the initiating token or another request identity through completion and ignore results that no longer match the current session.

Knowledge Base Used: Prescribing client workflows

Work in progress but good to note. Now just a stub and not real working code.

greptile-apps · 2026-09-07T16:06:12Z

+            Cmd.batch
+                [
+                    Cmd.ofMsg (UpdatePatient pat)
+                    match sessionInfo with
+                    | SessionContext.Launching token -> Cmd.ofMsg (SessionContextMsg(SessionContextMsg.Launch token))
+                    | SessionContext.Redeeming token -> Cmd.ofMsg (SessionContextMsg(SessionContextMsg.Redeem token))
+                    | _ -> Cmd.none


Anonymous Routes Retain Identity

An anonymous URL change does not reset state.SessionContext. After leaving a redeemed session, the title bar can therefore continue showing the previous user's name even though the new route was parsed as anonymous. Reset the session context to SessionContext.Anonymous during this transition so the displayed identity matches the active route.

Knowledge Base Used: Prescribing client workflows

@Zaid-Ajaj this is something that needs to fixed, I think.

halcwb

I think the comment on the problem of session context still showing user if switching to anonymous should work in this PR.

halcwb · 2026-09-08T05:02:55Z

@Zaid-Ajaj I think we should first agree on the implementation plan and then fix this pr. @7sharp9 if you can also have a look? Thanks!

7sharp9 · 2026-09-08T09:58:50Z

    | Interactions
    | Settings

+[<RequireQualifiedAccess>]


SessionContext is doing two jobs. parseSessionInfo : string list -> SessionContext can only ever return Anonymous | Launching | Redeeming, but the type also carries Error of string and Content of Deferred<SessionContent>.

This could benefit from splitting the responsibilities

7sharp9 · 2026-09-08T10:03:46Z


-        | UrlChanged sl ->
-            let pat, page, lang, discl, med = sl |> parseUrl
+        | UrlChanged newUrl ->


UrlChanged overwrites Patient unconditionally with parsePatient newUrl.

After a redeem sets Patient = Some content.Patient, the next navigation to any non-patient route parses None and wipes it.

Shouldn't the redeemed patient win? or the redeem flow should put the patient into the URL like the anonymous flow does?

7sharp9 · 2026-09-08T10:08:20Z

+    let parsePatient (urlParts: string list) =
+        urlParts
+        |> List.pairwise
+        |> List.tryFind (fun (a, b) -> a = "patient")


b is unused

Zaid-Ajaj added 5 commits September 6, 2026 04:26

feat(api): initial session interaction scaffold

d33a512

feat(api): implement token redeem logic

dab4f76

feat(api): better docs for parseSessionInfo

62cce32

feat(api): restructure token exchange and show progress in UI

7175f1f

Merge branch 'master' into zaid/initial-session-interactions

d24559c

# Please enter a commit message to explain why this merge is necessary, # especially if it merges an updated upstream into a topic branch. # # Lines starting with '#' will be ignored, and an empty message aborts # the commit.

Zaid-Ajaj requested a review from halcwb September 7, 2026 16:02

greptile-apps Bot reviewed Sep 7, 2026

View reviewed changes

halcwb requested changes Sep 7, 2026

View reviewed changes

Merge branch 'master' into zaid/initial-session-interactions

c6cba96

halcwb mentioned this pull request Sep 8, 2026

docs(client): implementation plan for the client launch sequence (#409) #579

Open

7 tasks

Merge branch 'master' into zaid/initial-session-interactions

b970395

7sharp9 reviewed Sep 8, 2026

View reviewed changes

7sharp9 approved these changes Sep 8, 2026

View reviewed changes

		\| SessionContextMsg(SessionContextMsg.Launched(SessionRedeemToken token)) ->
		state, Cmd.navigate ("session", [ "redeem", token ])

Uh oh!

Conversation

Zaid-Ajaj commented Sep 7, 2026

Description

Uh oh!

github-actions Bot commented Sep 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Test Results

Uh oh!

greptile-apps Bot commented Sep 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Confidence Score: 4/5

Summary

Diagram

Uh oh!

greptile-apps Bot Sep 7, 2026

Choose a reason for hiding this comment

Uh oh!

halcwb Sep 7, 2026

Choose a reason for hiding this comment

Uh oh!

greptile-apps Bot Sep 7, 2026

Choose a reason for hiding this comment

Uh oh!

greptile-apps Bot Sep 7, 2026

Choose a reason for hiding this comment

Uh oh!

halcwb Sep 7, 2026

Choose a reason for hiding this comment

Uh oh!

greptile-apps Bot Sep 7, 2026

Choose a reason for hiding this comment

Uh oh!

greptile-apps Bot Sep 7, 2026

Choose a reason for hiding this comment

Uh oh!

halcwb Sep 7, 2026

Choose a reason for hiding this comment

Uh oh!

greptile-apps Bot Sep 7, 2026

Choose a reason for hiding this comment

Uh oh!

halcwb Sep 7, 2026

Choose a reason for hiding this comment

Uh oh!

halcwb left a comment

Choose a reason for hiding this comment

Uh oh!

halcwb commented Sep 8, 2026

Uh oh!

7sharp9 Sep 8, 2026

Choose a reason for hiding this comment

Uh oh!

7sharp9 Sep 8, 2026

Choose a reason for hiding this comment

Uh oh!

7sharp9 Sep 8, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

github-actions Bot commented Sep 7, 2026 •

edited

Loading

greptile-apps Bot commented Sep 7, 2026 •

edited

Loading