We run `changeset version` during changelog generation, which causes
changesets to be consumed and the package.json versions to be bumped. We
need to calculate the same "target version" that the changesets tools
calculate so we can correctly replace the output of the changelogs to
the correct versions and do our other cleanup.
This change fixes the calculation to take into account the bump ranges
in the changesets.
## Description
This PR includes small improvements in the code coverage module.
1.) Add ability to skip coverage check in code coverage module in case
of regression.
2.) Fix glyph and use unicode characters for arrows.
3.) Improve code coverage readme.
4.) Add more details to the code coverage summary.
---------
Co-authored-by: Jatin Garg <jatingarg@Jatins-MacBook-Pro-2.local>
Co-authored-by: Alex Villarreal <716334+alexvy86@users.noreply.github.com>
## Description
Follow-up to https://github.com/microsoft/FluidFramework/pull/22732,
with a bit of cleanup from PR suggestions.
- Removes unnecessary config files and dependencies.
- Cleans up npm scripts.
- Adds the ESM output to code coverage configuration.
- Updates README in the sample app with basic instructions on how to
start it.
Generated release notes for the 2.4 release. The notes were generated using the following command:
```shell
flub generate releaseNotes -g client -t minor --outFile RELEASE_NOTES/2.4.0.md
```
Presence asserted connection when processing signals, but that doesn't
hold as signals may be queued and connection status might change along
the way.
Just skip an attempt to respond when not connected.
A long time ago (5acfef448f) we added
support in ContaineRuntime to parse op contents if it's a string. The
intention was to stop parsing in DeltaManager once that saturated. This
is that long overdue follow-up.
Taking this opportunity to make a few things hopefully clearer in
ContainerRuntime too:
* Highlighting where/how the serialization/deserialization of `contents`
happens
* Highlighting the different treatment/expectations for runtime v.
non-runtime messages during `process` flow
## Deprecations:
Deprecating use of `contents` on the event arg `op` for
`batchBegin`/`batchEnd` events, they're in for a surprise. I added a
changeset for this case.
While stashing blobs, we need to first send the blob attach op before
resolving the blob handle to keep order of ops correctly (blob attach op
and op referencing the blob). This change of order causes the stashed
container to have a blob attach op whose blob won't be used in case of
aborting the closeAndGetPendingLocalState call.
Instead of cleaning up the pending state, for now we will just accept
the fact that the blob attach op will be stashed with no usage. We could
come up with an optimization of this later on when our partners catch up
with our latest offline features.
This PR adds some benchmark tests to get coverage of the Runtime's
handling of ops when submitting and processing them. This can be used to
test out the perf impact of various configurations or proposed changes.
## Description
While looking at our pnpm version, I found two packages inside of client
other than the root specifying the pnpm version. This seems unnecessary.
This removes them, as well as the apparently unneeded workspace and
pnpm-lock from tools/markdown-magic.
## Description
Added a beta API to deep clone nodes in a tree. The properties of this
API are:
- It deep clones all persisted data associated with the node and its
subtree.
- It can clone primitive types as well.
- It can clone both hydrated and unhydrated nodes.
## Future considerations
One useful property of this API could be to replace identifiers in the
node's subtree. However, I am choosing to not do this in the first
iteration of this API. We can consider doing this as a follow up or when
there is a customer ask which will give us more details into what the
requirements are and how best to design it.
[AB#13000](https://dev.azure.com/fluidframework/235294da-091d-4c29-84fc-cdfc3d90890b/_workitems/edit/13000)
The test `Parallel Forks: Closes (ForkedContainerError and
DuplicateBatchError) when hydrating twice and submitting in parallel
(via Counter DDS)` has had some recent failures when running against
t9s.
Reading through the test again, the only idea I have so far is that
maybe one of the containers manages to submit the stashed ops before it
can pause the outbound queue after creation.
This change aims to close that gap.
## Description
Adds a new package `@fluid-experimental/ai-collab` with the first draft
of a library that simplifies integration with AI / LLM agents in
Fluid-based applications.
Also adds a sample application that leverages said package. NOTE: we
know already that the app will probably be re-written so we're not
spending more time fixing its source code.
---------
Co-authored-by: seanimam <105244057+seanimam@users.noreply.github.com>
Co-authored-by: Tyler Butler <tyler@tylerbutler.com>
## Description
[AB#19036](https://dev.azure.com/fluidframework/235294da-091d-4c29-84fc-cdfc3d90890b/_workitems/edit/19036)
Fix cobertura configuration for showing code covearge stats in client
repo. Currently running npm run test:coverage does not display code
coverage stats because lib files are not included in the config.
Since when running test for an individual package we run:
"test:mocha:esm", that is why lib files needs to be included for
coverage to be reported correctly.
---------
Co-authored-by: Jatin Garg <jatingarg@Jatins-MacBook-Pro-2.local>
ID Allocation ops are not resubmitted one-by-one like other ops, but
rather the ID Compressor is told to generate new ops once and for all
right at the start of the Resubmit flow (before calling
`PendingStateManager.replayPendingStates`). The original Batch ID isn't
available at that point, so there's no way to correlate the new ID
Allocation Batch to the original one.
In a forked container scenario, we can ignore the Batch IDs of ID
Allocation batches, knowing that the main batch will also be duplicated
and we'll detect that.
## Description
### Changes Made
Validation Improvement: Updated the validation logic to use
Number.isNaN(Number.parseFloat(value)) instead of isNaN. This ensures
that any non-number data is correctly identified and handled.
### Error Handling
For app insights handlers, retained the try-catch mechanism to continue
processing subsequent metrics even if an error occurs.
_For non-app-insight handlers, implemented a strategy to throw an error
and terminate the process when non-number data is encountered. This
provides a clear indication of unexpected data and prevents the
submission of potentially invalid values._
### Unit Tests
Added unit tests to cover scenarios involving non-number data in
customData. These tests ensure that the new validation logic works as
expected and helps prevent future regressions.
## Test result
~~~
@chentong7 ➜ /workspaces/FluidFramework/tools/telemetry-generator
(telemetry) $ npm run test
> @fluid-tools/telemetry-generator@1.0.0 test
> mocha --recursive "dist/test/**/*.test.*js" --exit
Writing test results relative to package to nyc/junit-report.xml and
nyc/junit-report.json
appInsightsCustomBenchmarkHandler
✔ should emit metrics to Azure App Insights
appInsightsExecutionTimeTestHandler
✔ should emit valid metrics to Azure App Insights
✔ should skip logging for invalid metrics
appInsightsMemoryUsageTestHandler
✔ should emit heap used avg and std dev metrics to Azure App Insights
✔ should skip metrics if values are not numbers
executionTimeTestHandler
✔ should emit execution time avg and std dev metrics to logger
memoryUsageTestHandler
✔ should emit heap used avg and std dev metrics to logger
✔ should throw an error for invalid heap used avg metric
✔ should throw an error for invalid heap used std dev metric
9 passing (12ms)
~~~
---------
Co-authored-by: Alex Villarreal <716334+alexvy86@users.noreply.github.com>
## Description
- Add metrics to know where time is being spent during session discovery
- Broken down into two primary pieces: verifyStorageToken and getSession
- GetSession is further broken down into three parts:
checkDocumentExistence, updateExistingSession, and createNewSession
- checkDocumentExistence is the DB call that is made to retrieve the doc
and see if it exists
- updateExistingSession will only happen if the session is not yet
alive/discovered
- createNewSession will only happen if the session is undefined (docs
created before the concept of service sessions)
---------
Co-authored-by: Brandon Diaz <“BrandonLouisDiaz@gmail.com”>
#### Description
Search for compatDetails in the code - all some usages can now be
removed. Maintaining this behavior has been a pain in tests, and it is
not a good feature.
It was only ever used for GC, and wasn't as useful (or safe) as
expected. See discussion in ADO:
https://dev.azure.com/fluidframework/internal/_workitems/edit/17024 -
RC1 clients don't know about TombstoneLoaded subtype
Fixes issue:
[AB#17024](https://dev.azure.com/fluidframework/235294da-091d-4c29-84fc-cdfc3d90890b/_workitems/edit/17024)
The full removal of this feature is planned for next sprint (10/14 -
11/1)
---------
Co-authored-by: Mark Fields <markfields@users.noreply.github.com>
Due to some bad pull/rebase, the PR
https://github.com/microsoft/FluidFramework/pull/21702 introduced
content that shouldn't exist in the main branch (based on the commit
c126bba051 (diff-5839274c7eb7f262c570edf94a75999ccf76913c6d7b9ec3d53152537a00b0cb)).
This PR is to address this issue.
## Reviewer Guidance
The review process is outlined on [this wiki
page](https://github.com/microsoft/FluidFramework/wiki/PR-Guidelines#guidelines).
> List any specific things you want to get reviewer opinions on, and
anything a reviewer would need to know to review this PR effectively.
> Things you might want to include:
>
> - Questions about how to properly make automated tests for your
changes.
> - Questions about design choices you made.
> - Descriptions of how to manually test the changes (and how much of
that you have done).
> - etc.
>
> If you have any questions in this section, consider making the PR a
draft until all questions have been resolved.
## Description
Updates transitive dependencies on `braces` from 3.0.2 to 3.0.3 to
address [CVE-2024-4068](https://nvd.nist.gov/vuln/detail/CVE-2024-4068).
A couple of applications of `flub modify lockfile --dependency braces
--version 3.0.3 --releaseGroup <release group>`, and some manual updates
in packages/release groups that we can't target with `flub`, basically
doing the same thing but manually (add an override in package.json,
install dependencies, remove override, install dependencies again to
clean up override from the lockfile).
In a few cases I got unrelated updates, mostly about node types, which I
reverted manually.
Server packages also got semver update from 7.6.0 to 7.6.3 which seems
fine.
Adds information about the new behavior of obliterate with endpoint
expansion to the documentation. The majority of the changes fall under
the "Endpoint Behavior" section, since conceptually the obliterate stays
mostly the same.
## Description
In October 2023, one of the "rebasing commits" tests timed out during
test stability testing.
For me locally these tests run as follows:
SharedTree benchmarks
rebasing commits
✔ @Benchmark @Measurement @ExecutionTime for 1 commits per peer for 2
peers (45ms)
✔ @Benchmark @Measurement @ExecutionTime for 5 commits per peer for 2
peers (56ms)
✔ @Benchmark @Measurement @ExecutionTime for 10 commits per peer for 2
peers (89ms)
✔ @Benchmark @Measurement @ExecutionTime for 1 commits per peer for 4
peers (72ms)
✔ @Benchmark @Measurement @ExecutionTime for 5 commits per peer for 4
peers (196ms)
✔ @Benchmark @Measurement @ExecutionTime for 10 commits per peer for 4
peers (398ms)
Since my system is much faster than CI, and CI has a default timeout of
2 seconds, its plausible that this could be an issue if CI has a really
slow run sometime.
This change reduces the size of test cases run when not in performance
testing mode so that the run now look like:
SharedTree benchmarks
rebasing commits
✔ @Benchmark @Measurement @ExecutionTime for 1 commits per peer for 2
peers (52ms)
✔ @Benchmark @Measurement @ExecutionTime for 2 commits per peer for 2
peers (40ms)
✔ @Benchmark @Measurement @ExecutionTime for 1 commits per peer for 4
peers (88ms)
✔ @Benchmark @Measurement @ExecutionTime for 2 commits per peer for 4
peers (132ms)
With this the worst case is now more than twice as fast.
This should have no impact on the tests when run as performance tests.
Tracked internally by
https://dev.azure.com/fluidframework/internal/_workitems/edit/6003
## Description
Modify comment for code coverage.
Add the line coverage summary to the summary.
Co-authored-by: Jatin Garg <jatingarg@Jatins-MacBook-Pro-2.local>
## Description
This cleans up a section of the object node tests which used schema
types in a complicated generic way that's fragile and hard to work with.
When rewriting these tests, I focused the new ones on testing aspects
that actually have special logic and are likely to break instead of just
different value types. Thus the tests now cover the odd normalization
cases of numbers.
These tests found a couple of issues:
- unhydrated node handling of null was incorrect (see changeset)
- Some type errors were thrown for invalid user input. TO help keep it
easy to tell which errors are our bugs and which are app bugs I've made
these fluid usage errors.
- A needless check for NaN was included where the check for isFinaite
would handle it correctly (Number.isFinite considers NaNs to not be
finite: comment already calls out NaN and it has test coverage so this
seems like a safe change.)
Adds support for creating fluid-build tasks from config only, by
declaring the command corresponding to the task and providing globs for
input and output files.
- Adds two new settings to the fluid-build config.
- `declarativeTasks?: DeclarativeTasks;` - a mapping of
executable/command to input/output globs and a gitignore setting that
controls whether gitignore rules are applied to the input/output globs.
- `multiCommandExecutables?: string[]` - a list of executables that have
subcommands, like `flub` or `oclif`. This is needed to ensure that the
commands in the declarative tasks are parsed correctly.
- Added types to represent "task handlers" - functions that create
LeafTask objects to handle tasks.
- Added support for free functions that return instances of LeafTasks -
this is needed so that task handlers can be dynamically created. Task
subclasses with constructors still work as before.
- Added a new DeclarativeTaskHandler class that handles the declarative
tasks. It is a typical Task class, but the primary way it is used is via
a factory function. This allows us to pass in the configuration settings
for each task dynamically but re-use the DeclarativeTask class for all
the core functionality.
- Defined new declarative tasks for oclif, jssm-viz, and syncpack in the
root fluid-build config. These won't take effect until the new version
of build-tools is integrated into client.
- New dependency: globby - globby is helpful because it can auto-apply
gitignore rules which we need to do for some tasks' input/output globs.
[AB#13203](https://dev.azure.com/fluidframework/235294da-091d-4c29-84fc-cdfc3d90890b/_workitems/edit/13203)
A skipped test to illustrate a bug found from adding sided obliterate
ops to the conflict farm stress tests. Once sidedness is enabled and the
bug is fixed, the .skip will be removed from the test.
[AB#2729](https://dev.azure.com/fluidframework/internal/_workitems/edit/2729),
[AB#2730](https://dev.azure.com/fluidframework/internal/_workitems/edit/2730)
This PR is a prototype for improving the Test - DDS Stress line by using
a numeric stressLevel instead of a boolean isStress. This change allows
for more granular control over whether to use stress runs and to what
degree.
The follow-up tasks include:
1. Integrating this functionality (potentially as a stage) into the CI
build pipeline with a light stress level mode, so it can be triggered in
the PR gateway.
2. Creating a long-running pipeline to execute the DDS stress tests with
a heavy stress level mode, scheduled to run periodically during off-peak
hours, similar to the test stability pipeline.
[Guidelines for Pull
Requests](https://github.com/microsoft/FluidFramework/wiki/PR-Guidelines#guidelines).
## Reviewer Guidance
The review process is outlined on [this wiki
page](https://github.com/microsoft/FluidFramework/wiki/PR-Guidelines#guidelines).
> List any specific things you want to get reviewer opinions on, and
anything a reviewer would need to know to review this PR effectively.
> Things you might want to include:
>
> - Questions about how to properly make automated tests for your
changes.
> - Questions about design choices you made.
> - Descriptions of how to manually test the changes (and how much of
that you have done).
> - etc.
>
> If you have any questions in this section, consider making the PR a
draft until all questions have been resolved.
---------
Co-authored-by: Abram Sanderson <Abram.sanderson@gmail.com>
ODSP targeted signal tests are consistently failing due to reuse of
socket references in ODSP driver. These tests can be re-enabled once
targetClientId is included in the return signal from PushChannel.
in ODSP, we can't load a container offline and send a server request to
create a blob because our call would not be complete, specifically we
would lack the epoch value which is set until we connect to the delta
stream, ending up with a 'ODSP fetch error [400]' response.
Even though this problem is worth tackling separately I believe both
affected tests are not specifically testing this behavior so I changed
them slightly to send a createBlob request while being disconnected
instead of using our loadOffline function. Both tests are connecting
anyway after creating the blob and the relevant asserts happen after
that part of those tests.
I added another test which replicates the issue and skip it in ODSP for
now. If we want to solve the initial issue, we would need to stash the
epoch info in our serialized state.
[AB#19035](https://dev.azure.com/fluidframework/235294da-091d-4c29-84fc-cdfc3d90890b/_workitems/edit/19035)
---------
Co-authored-by: Abram Sanderson <Abram.sanderson@gmail.com>
1. Add infrastructure for custom System Workspace to handle internal
states including ClientConnectionId to ClientSessionId.
2. Move audience support to System Workspace
3. Add `attendeeJoined` implementation
4. Add test coverage for new attendee's joining and consistency of
lookup. New test cases:
```
PresenceManager
✔ throws when unknown attendee is requested via `getAttendee`
when connected
attendee
✔ is announced via `attendeeJoined` when new
already known
✔ is available from `getAttendee` by connection id
✔ is available from `getAttendee` by session id
✔ is available from `getAttendees`
✔ is NOT announced when rejoined with same connection (duplicate signal)
✔ is NOT announced when rejoined with different connection and current information is updated
```
5. Update general update protocol to always include client connection id
-> current session id entry to ensure all updates are always working
with known (already registered) session id even if a prior join or
broadcast were missed.
Move signal telemetry and tracking to helper methods
- add processSignalForTelemetry and add comments
- add submitEnvelopedSignal that handles tracking updates a little
closer to submission
The mocha-json-output-reporter is failing which I was able to determine
via trial and error by adjusting the reporters, it also appears to be
essentially unsupported. It seems we only use it for inline logs in our
ci build output, which shouldn't be necessary as we have the test
results separately in the test tab. I think the best solution is to just
remove this.
Alex Villarreal
Tyler Butler
Jatin Garg
Matt Rakow
jzaffiro
Joshua Smithrud
Jason Hartman
Mark Fields
Daniel Madrid
Craig Macomber (Microsoft)
Navin Agarwal
Tong Chen
yunho-microsoft
Brandon
MarioJGMsoft
Kian Thompson
clarenceli-msft
yann-achard-MS
Tony Murphy
WillieHabi