DRAFT: Preliminary presence runtime schema validation support

[tylerbutler]

Adds preliminary support for runtime validation of presence data. I am mostly interested in feedback about the signature changes, the types, and where I put them.

For ease of review, there are three commits that can be reviewed separately.

• core presence changes
• tests - not working
• presence-tracker updates

Update April 9

The change now incorporates some of the initial feedback.

1. validator and controls are now part of an options object rather than direct function args.
2. validator is always optional in Latest and LatestMap
3. validators all have the same signature but are passed metadata that can be used to adjust behavior. The only metadata currently provided is a key property that will be set if the value being validated is from a ValueMap.

Not yet addressed:

• Storing validated data locally and ensuring data sent over the network is never flagged as valid without validation.

[tylerbutler]

Should be optional.

[jason-ha]

  ];

This is a tricky aspect.
Here we are providing access to the new value as a push to the customer. But we haven't validated the value.
A getter for value would be fine, but we'd have to adjust the return type to allow undefined or throw on failed validation.

---

Refers to: packages/framework/presence/src/latestValueManager.ts:195 in cdaeb15. [](commit_id = cdaeb15, deletion_comment = False)

[jason-ha]

  return [

Is the valid property effectively cleared here because we rebuild the entry in mergeValueDirectory?
Otherwise, nowhere is the valid state being cleared on update AFAICT. It could be done in the statestore. The implementation is a little hard to trace - I think the bottleneck may be mergeValueDirectory in presenceStates.ts.

---

Refers to: packages/framework/presence/src/latestValueManager.ts:188 in cdaeb15. [](commit_id = cdaeb15, deletion_comment = False)

[jason-ha]

valid can be added here but it will need to be removed from ClientUpdateEntry and any places calling with that.
It may be that we need to create a separate type for remote versus local value state.
Local value state which should be the only think that ever is sent as ClientUpdateEntry should never have valid (as we rely on caller to always provide confirming values).
So maybe the stripping of valid would just need to happen when generating the complete update in response to a join. (And eventually that should be less common code path when we start using targeted signals.)

[jason-ha]

Is key useful? Required?
Maybe the validator functions should all follow (unvalidatedData: unknown, metadata: ...): T | undefined and we could stick extra info in metadata.
I function declared as (unvalidatedData: unknown): T | undefined should still be acceptable as validator.

[tylerbutler]

Not sure I understand. Are you suggesting there be a single type for all validators, and pass metadata in the second
function arg that customer code can use to determine what logic to run?

Or are you thinking more like two different types that vary on the type/contents of the metadata arg?

I'm not clear how customer code can declare validators for each key, so I thought the validator for maps would use the
key to determine what validator to run (i.e. the map validator would return a value validator). Seems like that logic is still necessary, but would be moved inside the
customer's code to read the metadata and act accordingly?

[github-actions]

🔗 No broken links found! ✅

Your attention to detail is admirable.

linkcheck output

> fluid-framework-docs-site@0.0.0 ci:check-links /home/runner/work/FluidFramework/FluidFramework/docs
> start-server-and-test "npm run serve -- --no-open" 3000 check-links

1: starting server using command "npm run serve -- --no-open"
and when url "[ 'http://127.0.0.1:3000' ]" is responding with HTTP status code 200
running tests using command "npm run check-links"


> fluid-framework-docs-site@0.0.0 serve
> docusaurus serve --no-open

[SUCCESS] Serving "build" directory at: http://localhost:3000/

> fluid-framework-docs-site@0.0.0 check-links
> linkcheck http://localhost:3000 --skip-file skipped-urls.txt

Crawling...

Stats:
  163664 links
    1315 destination URLs
    1547 URLs ignored
       0 warnings
       0 errors

[tylerbutler]

Superseded by more recent PRs. Closing.