The markdown-magic project is now a part of the client release group,
but changes to it were not triggering client CI builds. This change
should address that.
One of the valuable things the `release` command does is run a series of
checks to make sure the branch is ready to serve as the base of a
release branch. These checks may require changes, such as tagging
asserts or generating changelogs. These changes need to be merged before
the release branches are created to ensure the release branches have
those changes.
However, the release command runs these checks and immediately exits if
one fails, and it also makes local changes when needed. It is not really
possible to just run the checks and get their results without making
changes.
This PR implements a new `release prepare` command that runs these
checks without making changes and reports the results, along with a
command that may resolve the problem.
### Implementation notes
I considered using the StateMachineCommand as a base and replicating the
checks exactly as they're done in the `release` command, but that
pattern is not as great as I once thought. It would require creating a
new state machine, duplicating pieces of the release one, and it
intuitively feels too complicated for this use. It's arguably too
complicated for its current use in `release`, and this is a much simpler
command.
I also considered adding a new flag to the release command, but it's
already so complex that adding a new flag multiplies it that much more.
Instead, I copied and refactored the core of the existing checks into
new functions that require fewer arguments and return more useful data
than the state machine handler functions.
---------
Co-authored-by: Craig Macomber (Microsoft) <42876482+CraigMacomber@users.noreply.github.com>
Enable noUncheckedIndexedAccess for Local Driver
The property noUncheckedIndexedAccess is being enabled to improve type
safety by making the TypeScript compiler assume all arrays are sparse,
which requires runtime validation or non-null assertions for indexed
access. This aims to catch potential issues with type changes and ensure
API semver compliance
[AB#8216](https://dev.azure.com/fluidframework/235294da-091d-4c29-84fc-cdfc3d90890b/_workitems/edit/8216)
Enable noUncheckedIndexedAccess for ODSP URL Resolver
The property noUncheckedIndexedAccess is being enabled to improve type
safety by making the TypeScript compiler assume all arrays are sparse,
which requires runtime validation or non-null assertions for indexed
access. This aims to catch potential issues with type changes and ensure
API semver compliance
[AB#8216](https://dev.azure.com/fluidframework/235294da-091d-4c29-84fc-cdfc3d90890b/_workitems/edit/8216)
Enable noUncheckedIndexedAccess for Driver Base
The property noUncheckedIndexedAccess is being enabled to improve type
safety by making the TypeScript compiler assume all arrays are sparse,
which requires runtime validation or non-null assertions for indexed
access. This aims to catch potential issues with type changes and ensure
API semver compliance
[AB#8216](https://dev.azure.com/fluidframework/235294da-091d-4c29-84fc-cdfc3d90890b/_workitems/edit/8216)
Enable noUncheckedIndexedAccess for Replay Driver. I will update the
TODOs with the standardized comment
The property noUncheckedIndexedAccess is being enabled to improve type
safety by making the TypeScript compiler assume all arrays are sparse,
which requires runtime validation or non-null assertions for indexed
access. This aims to catch potential issues with type changes and ensure
API semver compliance
[AB#8216](https://dev.azure.com/fluidframework/235294da-091d-4c29-84fc-cdfc3d90890b/_workitems/edit/8216)
Enable noUncheckedIndexedAccess for File Driver
The property noUncheckedIndexedAccess is being enabled to improve type
safety by making the TypeScript compiler assume all arrays are sparse,
which requires runtime validation or non-null assertions for indexed
access. This aims to catch potential issues with type changes and ensure
API semver compliance
[AB#8216](https://dev.azure.com/fluidframework/235294da-091d-4c29-84fc-cdfc3d90890b/_workitems/edit/8216)
Enable noUncheckedIndexedAccess for Driver Web Cache
The property noUncheckedIndexedAccess is being enabled to improve type
safety by making the TypeScript compiler assume all arrays are sparse,
which requires runtime validation or non-null assertions for indexed
access. This aims to catch potential issues with type changes and ensure
API semver compliance
[AB#8216](https://dev.azure.com/fluidframework/235294da-091d-4c29-84fc-cdfc3d90890b/_workitems/edit/8216)
Cell isn't a DDS we actually expect customers to use, but there is
nothing in its documentation to indicate such. This PR adds notes to
this effect, and also updates the package README to use our complete
README template.
Some light refactoring:
* Rename `IPendingBatchMessage` to `PendingMessageResubmitData` to
better reflect its purpose
* Rename `IBatch.content` to `IBatch.messages`
* Add/use helper for strongly typed access to batch metadata
* Remove redundant `reSubmit` callback for PSM's use; it can/should
always use `reSubmitBatch`.
* Everything is always batches in Turn-Based mode, and there's no harm
in treating it the same for Immediate mode.
* There's no functional change here in this PR, thanks to [this bug
fix](https://github.com/markfields/FluidFramework/blob/main/packages/runtime/container-runtime/src/containerRuntime.ts#L1555)
a few months back.
## Description
Adds a reference to https://semver-ts.org above relevant compiler
settings in our base tsconfig.
---------
Co-authored-by: Abram Sanderson <absander@microsoft.com>
The property-changeset package was changed to dual emit CJS and ESM, and
the `main`/`types` field was changed to point to ESM. Unfortunately, the
property-properties package has a dependency on this package and it is
CJS-only and still using Node10 module resolution.
To address this incompatibility, I have reverted the changes to the main
and types fields - they now point to the CommonJS entrypoint.
## Description
Update build tools to TypeScript 5.4. This caused a difference enum type
checking detected by our type test validation suite which got updated
accordingly.
In #21641 I tried to fix version comparisons between semver and RC
prereleasse builds. Unfortunately, the fix was flawed because the scheme
detection was not run on the input version, but rather the "internal
version" in the case of internal/RC builds. This caused patch releases
to get identified as major releases in the RC pipelines, which in turn
causes GH releases to be created incorrectly.
I corrected the code by running schema detection earlier in the
function, and I added several test cases around RC versions to ensure
the bug was addressed.
Adds a check to an existing policy that checks the repository.directory
field in package.json is set correctly.
Changes were pre-applied to the repo in #21689.
This change is purely about refactoring to make the code easier to
modify later. The change moves all the snapshot and summary
implementation for the blob manager into a single file and lays out a
pattern for versioning. This change also moves to free functions and
removes statics where possible as they are more bundle efficient than
members, and are easier to test and maintain.
## Description
tsCompile.ts just does nothing when parseCommandLine returned undefined,
and parseCommandLine returns undefined if tsLib.parseCommandLine reports
errors.
When the command was 'tsc --build ./src/test/tsconfig.cjs.json --force',
an error "Compiler option '--force' may only be used with '--build'." is
reported (due to https://github.com/microsoft/TypeScript/issues/59095 ),
which used to be dropped.
This change ensures the error is at least printed (confirmed to work
with manual testing), as well as removed --force to work around this
specific error.
This workaround may convert cases which silently error into having an
incremental build bug in some cases. This is required to enable
https://github.com/microsoft/FluidFramework/pull/21579 which will allow
us to detect bad d.ts file generation by importing d.ts files from test
schema in the tree tests. As we have multiple know issues with the d.ts
file generation, testing it is valuable. Given we already have known
incremental build issues with tests (cleanup of extra files), so we have
to clean build them occasionally, this seems like a decent tradeoff.
Our github wiki isn't really tailored for public consumers; that's what
our website is for.
This PR updates our README "Help" template (and all consuming READMEs)
to point users exclusively to our website for learning.
[AB#8034](https://dev.azure.com/fluidframework/235294da-091d-4c29-84fc-cdfc3d90890b/_workitems/edit/8034)
### Description
Add data virtualization tests in which we create, load, and modify
loadinggroupId datastores. What is added to the stress tests are these
sets of actions during sending ops:
- These datastores will be randomly created with some groupId based on
the size of the groupId map
- These datastores will be randomly loaded (pure reading)
- These datastores will be randomly modified (an op sent via the root
directory).
On submit, the PendingStateManager stores the batch's starting CSN along
with each message. We need the corresponding information for incoming
messages too, for two reasons:
1. We can assert that they match as we process incoming acks for local
messages
2. We need it to compute batch ID, when checking for the same batch
coming from a forked container.
Today, two things happening in RemoteMessageProcessor keep the correct
info from flowing to the PSM:
1. Grouped Batches overwrite clientSequenceNumber with the index into
the batch
2. Without Grouped Batching, batch messages are processed one-by-one, so
the context of the start of the batch is not available when later
messages are sent to PSM.
Here's the fix - the RemoteMessageProcessor has the full context and can
return the batch's starting CSN with each message, irrespective of
grouped batching, compression, chunking, etc.
## Description
Fetch-tool has some logic to download 'as many ops as possible' when
older ops have been deleted. This logic appears to not have been updated
at some point for a new error format coming from odsp-driver, which
caused fetch-tool to choke before downloading/writing messages.json with
an unintuitive error. This change fixes that and makes future changes to
the 410 format give a more clear error message.
---------
Co-authored-by: Abram Sanderson <absander@microsoft.com>
## Description
Replaces our current authentication flow to odsp by leveraging
\@azure/identity and \@azure/identity-cache-persistence. This generally
simplifies the setup of fetch-tool and comes with two security benefits
over the previous setup:
1. \@azure/identity uses the PKCE extension to the authorization code
flow
2. Cached credentials are encrypted before being stored on disk
I've included a couple smaller fixes/improvements to fetch-tool's output
to help diagnose issues.
---------
Co-authored-by: Abram Sanderson <absander@microsoft.com>
There can be scenarios such as DB rollback in server, where the latest
snapshot is lost but the corresponding summary ack is still present.
Currentlty, if a summarizer receives an ack that is newer that the
summary it's tracking, it will fetch latest snapshot and close. So, in
the above scenario, the summarizer would be stuck in loop fetching
snapshot and closing corrupting the document. There is no way out of
this state.
I have added tests for the following scenarios which includes the one
described above:
- A summarizer receives a summary ack that is newer and it fetches the
corresponding snapshot.
- A summarizer receives a summary ack that is newer but it fetches an
older snapshot.
Once we have a fix for the bug described above, we can use the above
tests to validate it.
There are couple other changes:
- Combined tests in
`summarizeWithOutOfOrderDataStoreRealization.spec.ts` and
`summarizationEdgeCases.spec.ts` as they were related.
- Fixed "Fluid.ContainerRuntime.Test.CloseSummarizerDelayOverrideMs"
setting to done before each test and reset after.
[AB#8334](https://dev.azure.com/fluidframework/235294da-091d-4c29-84fc-cdfc3d90890b/_workitems/edit/8334)
typescript builds against `odsp-client` must use `/beta` import spec
path to import `@beta` APIs.
Correct use within examples including mismatched `TokenResponse` import.