Repository navigation
Conversation
…ed or yanked (#75919) (#75924) Constraints for an Airflow release candidate pin the provider wave being voted on at its rc versions, and commit them onto the shared constraints-X-Y branch. The next regular generation for the vX-Y-test branch resolves without pre-releases, so it saw the older finals as a provider downgrade and failed - the v3-4-test canary has been red since 3.4.0rc1 for exactly that reason, although nothing was yanked. The final release has the opposite gap: it ignored the candidates, so a provider rc that was neither released nor yanked was silently passed over and the released constraints never recorded that decision. It now has to be made, and the run says which providers it is still waiting on. The alert that should have reported the canary failure never reached Slack because the action was not told which API method to call, and the twice-daily CI notification announced "All passing" because it read a run that was still in progress, whose missing conclusion looked like no failures. (cherry picked from commit eeae004) Generated-by: Claude Opus 5 Co-authored-by: Jarek Potiuk <jarek@potiuk.com>
The scripts package supports Python 3.11 from its initial patch release, but tarfile added the extractall filter argument in 3.11.4. Keep the opt-in cache integration test usable across the supported 3.11 patch range. (cherry picked from commit 62934e4) Co-authored-by: Parv Goyal <parvgoyal1321@gmail.com>
…ad of prek (#75872) (#75914) These checks build and run each SDK's serializer, so as prek hooks they needed a full Go, Java or Node toolchain and took minutes on every commit touching Airflow's serializer. They are tests, not static checks, so they now run as a CI test job that sets up only the toolchain of the SDK it checks, for the SDKs whose inputs changed. (cherry picked from commit 71bdce5) Co-authored-by: Pierre Jeambrun <pierrejbrun@gmail.com>
…lk selection (#75862) (#75867) * Stop requesting the details of an empty Dag id after a bulk selection The Task Instances list keeps its bulk Clear dialog mounted once every row is unselected. With nothing to clear, the dialog's Dag id was an empty string, which still enabled the auto-refresh lookup and sent GET /dags//details, answered with a 404. * Leave the Clear dialog's Dag id undefined when there is nothing to clear An empty-string fallback on the shared Dag id lets any later use send it unnoticed. Only the two Dag and Dag run lookups need a string, and they run for a single run, when the Dag id is always set. (cherry picked from commit 60d692b) Co-authored-by: Pierre Jeambrun <pierrejbrun@gmail.com>
… reparsing (#73433) (#75939) * Stop a stale callback stat from forcing constant Dag file reparsing A callback pins bundle_version on its DagFileInfo while the bundle scan leaves it unset, so one file can hold two _file_stats entries. Collapsing them by presence_key with a dict comprehension keeps whichever was inserted last, which is the callback entry, and that entry is never refreshed afterwards because later parses write to the scan key. Its frozen last_finish_time makes the file look long unparsed, so min_file_process_interval never excludes it and the processor reparses it on every loop until it restarts. Resolve the collapse by the most recent parse instead. _sort_by_mtime and processed_recently share the same lookup, which previously disagreed with each other on which duplicate wins. * Prefer the bundle scan's stat when resolving a file's parse time Callback runs never record a parse of the current file: a callback-only stat has no last_finish_time, and a timed-out callback processor is stamped anyway. Fall back to a versioned stat only when the file has no scan entry. * Use only scan stats for queueing and parse metrics * Use a neutral name for the duplicate-entries test (cherry picked from commit 72628b5) Co-authored-by: Vuong Hoang <57295051+vuonghoangbntt@users.noreply.github.com>
#75960) Almost every screenshot on the UI overview page was shown twice, once per theme, which roughly doubled the page length. Each pair is now a sphinx-design tab set in one sync group, so choosing a theme on any screenshot switches them all and the choice is remembered for the browser session. (cherry picked from commit 7468d31) Co-authored-by: Ash Berlin-Taylor <ash@astronomer.io>
* [v3-4-test] Fix dashboard Active Dags filtering (#75350) (cherry picked from commit fa160f8) Co-authored-by: Anzin Mohammed <anzinmhd765@gmail.com> * UI: Fix the Dag filters test that fails lint and vitest (#75963) (cherry picked from commit f605f10) --------- Co-authored-by: Anzin Mohammed <anzinmhd765@gmail.com> Co-authored-by: Pushkal Gupta <161060351+Pushkal-Gupta@users.noreply.github.com>
…5384) (#75950) Array and primitive documents cannot represent a mapping of variable names to values and can otherwise enable unintended imports. (cherry picked from commit eafb6ed) Co-authored-by: Himanshu Chawla <himanshuchawla0807@gmail.com> Co-authored-by: Himanshu Chawla <241715894+himanshuchawla0807-gif@users.noreply.github.com>
…g generation (#75989) (#75990) A regular constraints refresh resolves its pins against the constraints branch as it is when the run starts, then commits them on top of the branch as it is when the run ends. When Release constraints commits a release candidate's pins in between, the refresh overwrote them with pins resolved against the older baseline, and the push still succeeded because it was an ordinary fast-forward. The two workflows run in different concurrency groups, so nothing serialised them. The publish now fails instead and asks for a re-run, which then starts from the candidate's constraints. (cherry picked from commit 92bbf67) Generated-by: Claude Opus 5 Co-authored-by: Jarek Potiuk <jarek@potiuk.com>
…76008) * Name the native Dag k8s tests so the lang-SDK job selects them The lang-SDK Kubernetes job runs `-k TestLangSdk`, which matched only TestLangSdkMixedLanguageDag. The native Java and TypeScript classes were deselected, so Kubernetes verified stub tasks only. * Run the native Go Dag on Kubernetes Go Dag parsing landed with ExecutableDagImporter, and the compose e2e covers it, but the Kubernetes harness provisioned no Go native Dag bundle, so the Go class was a skipped placeholder. `breeze k8s setup-lang-sdk-test` now packs `go-sdk/example/native` into a `lang-sdk-native-go` bucket, served as a Dag bundle. The single ExecutableCoordinator already parses any executable bundle in every Dag bundle, and the `golang` queue is already routed, so no coordinator config changes. * Serve the typescript_example handlers from ts-task-handlers The native TypeScript Dag's trigger_downstream starts a typescript_example run and waits for it, but that Dag's stub tasks could not start: the only bundle in ts-task-handlers declares lang_sdk_mixed_language, so every task failed to launch and the awaited run failed. The gap was invisible while the native Dag tests were deselected. --------- (cherry picked from commit 8401a19) Co-authored-by: Jason(Zhe-You) Liu <68415893+jason810496@users.noreply.github.com>
…or modals (#75958) (#75987) * Make the bundle name less prominent in the Dag import error modals The bundle name was the first, bold item of each import error, so it drew more attention than the file that failed to parse. With a single bundle it carries no information at all. * Label the bundle as Bundle in the Dag import error modals (cherry picked from commit 38b3c45) Co-authored-by: Pierre Jeambrun <pierrejbrun@gmail.com>
…5984) (#75993) A loop's gate can explain itself -- LoopDecision carries a reason -- but the only places that showed one were a single task instance's header and the group header's final outcome. Seeing why a loop ran as long as it did meant opening each pass in turn and reading them off one at a time. Loops already report every pass in one summary, so this needs nothing new from the API. Picking a pass scopes the group's task instances to it, since reading why a pass decided as it did tends to lead to the tasks it ran. (cherry picked from commit 6e6ae1a) Co-authored-by: Brent Bovenzi <brent@astronomer.io> Co-authored-by: Claude <noreply@anthropic.com>
…ey can use (#75833) (#75992) * Size CI test jobs on RunsOn runners to the parallelism they can use Jobs that run tests with --run-in-parallel start one serial pytest per test type, so they never use more CPUs than they have test types. On RunsOn, splitting core test types into two jobs only doubles the jobs: each half still lasts as long as its slowest test type, and the out-of-memory risk the split guards against on public runners does not apply to the larger RunsOn runners. The lowest-dependencies provider jobs left their 32 CPUs partly idle, and the integration-core and system tests ran a single pytest on 32-CPU runners. Generated-by: Claude Opus 5 * Run provider tests one provider per test type on RunsOn runners Grouping all providers but the long-running ones into one test type left the provider jobs waiting on that group's single serial pytest while the other CPUs idled. The Non-DB jobs run every provider in one xdist pytest, where splitting test types only adds entries, so they get the providers unsplit. Generated-by: Claude Opus 5 * Give docker on RunsOn runners enough address pools for parallel test runs Each test type of a parallel test run is a docker compose project with its own network. Docker's default address pools fit about 30 networks, so provider jobs running a test type per CPU on 32-CPU and larger runners failed with "all predefined address pools have been fully subnetted". Generated-by: Claude Opus 5 * Split the longest-running provider tests into several test types on RunsOn Once every provider runs as its own test type, a job lasts as long as its slowest provider, and amazon, google and standard each take far longer than the rest as a single serial pytest. Splitting them lets the large RunsOn runners work on their parts at once. Lowest-dependencies jobs are sized by test-type count, so a change touching a few providers keeps one job. Generated-by: Claude Opus 5 * Keep split provider test types out of compose project and artifact names Docker Compose project names and GitHub artifact names reject the colon that names a part of a split provider. Generated-by: Claude Opus 5 * Skip split provider test types whose provider is ignored A split provider part selects a folder inside the provider's tests, and pytest runs an explicitly selected path even when its provider folder is ignored, so a skipped or excluded provider's parts would still run. Generated-by: Claude Opus 5 * Fit RunsOn runner sizes to the work of each job and record their CPU and memory use Several jobs ran a single process, or a minute or two of work, on 32-CPU or 8-CPU runners, and fourteen Helm unit test jobs each spent more time preparing the image than running their tests. Charting each job's CPU and memory use lets the size classes be set from measurements rather than from how the jobs are expected to behave. Generated-by: Claude Opus 5 * Skip ignored test selections by the paths the test type selects The check for an empty run treated the first remaining argument, or any path-like argument, as a test selection, so option values such as the "8" of "-n 8" or a path passed to --rootdir decided whether tests ran. It now compares the ignored folders with the paths the test type itself selects, and passes paths the user names explicitly to pytest as they are. Generated-by: Claude Opus 5 * Reject split provider test types where all test types share one pytest Under xdist every test type runs in one pytest process, where the --ignore arguments of a provider's other part would silently be dropped or would remove its sibling parts, so the wrong tests would run. Generated-by: Claude Opus 5 * Count only test folders as the selections of a test type Test suites such as All-Postgres add pytest options with values, which were taken for selected test paths, so a run whose every test folder was ignored still started pytest with nothing selected. Generated-by: Claude Opus 5 * Run only its own test type in each worker of a parallel test run Each worker kept the whole list of test types, so with --skip-db-tests every worker selected the folders of all of them. Generated-by: Claude Opus 5 * Raise the AIO limit on RunsOn runners for parallel MySQL tests A few dozen MySQL servers running at once exhaust the default fs.aio-max-nr, and InnoDB then fails with "io_setup() failed with EAGAIN". Generated-by: Claude Opus 5 * Keep the provider compatibility tests on the grouped provider test types Each test type of a compatibility test installs an Airflow version and the providers before running, so listing every provider as its own test type multiplied those installs and the jobs ran out of time. (cherry picked from commit 083b82d) Generated-by: Claude Opus 5 Co-authored-by: Jarek Potiuk <jarek@potiuk.com>
#76022) An incremental registry build downloads the bucket's providers.json and modules.json, merges its own providers in and syncs them back. Docs publishes call it, release managers fire subset and fix-up publishes, and the backfill writes the same bucket, so two of them overlapping silently drop whichever finished first from the registry index. Docs publishes to one bucket and the two constraints publishers had the same exposure in smaller form. Provider and Airflow docs land in different paths, so those two kinds of docs sync keep running side by side. The packages-metadata.json they both rewrite from a scan of the whole bucket moves to its own job, serialised per bucket, using new --skip-packages-metadata and --packages-metadata-only flags of publish-docs-to-s3. The Docker Hub release grouped on the bare version string, which any other workflow using a version as its group would collide with. (cherry picked from commit c6a077b) Generated-by: Claude Opus 5 Co-authored-by: Jarek Potiuk <jarek@potiuk.com>
…ty run fields (#76027) (#76028) When a task instance failed and was put up for retry, `prepare_db_for_next_try` copied every column of the failed attempt into the new one, so the waiting attempt showed the previous attempt's start date, end date, duration, hostname and pid in the API and UI. The retry deadline was computed from that copied end_date, so it could not simply be nulled out. We now store the deadline on the waiting attempt as `retry_at`. The Execution API deliberately avoids loading the serialized Dag, and loading it on every retry just to compute a delay would undo that. A retry reported by a worker therefore arrives without a deadline, and the scheduler computes and stores it on its first pass over the run. Until then, and for rows already waiting at upgrade time, the deadline is computed from the previous attempt's end date. Because the delay is fixed at that point, changing retry_delay in a new Dag version no longer retimes a retry that is already waiting. The column is ret-conned in tothe 3.4.0 migration that made each attempt its own task_instance row, since that is where a waiting retry became a separate row inheriting the failed attempt's fields. Anyone who has already migrated to RC1 will need to manually apply this, or recreate their DB: ```sql -- PostgreSQL ALTER TABLE task_instance ADD COLUMN retry_at TIMESTAMP WITH TIME ZONE; -- MySQL ALTER TABLE task_instance ADD COLUMN retry_at TIMESTAMP(6) NULL; -- SQLite ALTER TABLE task_instance ADD COLUMN retry_at DATETIME; ``` The scheduler has always skipped dependency evaluation for retries that are not yet due. A waiting retry has already passed its trigger rule, so an upstream that changes state during the wait is only acted on once the retry is due or the run checks for a deadlock, and the end state is the same. Doesn't really affect anything but people messing about with clearing upstream tasks etc, but the eventually consistent state remains the same before and after this change, it just might take more time to reach it `emit_state_change_metric` relied on the copied end_date to skip retries, so scheduled_duration and queued_duration are now also emitted for retries and cleared tasks. Each attempt has its own scheduled and queued times, so these samples are accurate. (cherry picked from commit 155560d) Co-authored-by: Ash Berlin-Taylor <ash@astronomer.io>
…#76038) * Refresh the hardened base image mirror every six hours Docker rebuilds the hardened images in place and moves the dhi.io apt repository on at the same time. With a weekly mirror, the base images Airflow builds on lag the repository by up to a week, and any apt install whose dependencies were rebuilt in between fails: build-essential currently cannot be installed because the mirrored base has an older libbz2 than the bzip2 the repository offers (docker-hardened-images/catalog#689). Mirroring copies manifests between registries without pulling layers, so running it several times a day is cheap. Generated-by: Claude Opus 5 * Pin the hardened base images to digests the CI has passed on Building on the mirror's moving tags made CI non-reproducible: any refresh of the mirror changed the image every build started from, without a change in the repository and without the full CI having run on it. A CI run could pass or fail depending only on when it ran, and rebuilding the same commit later gave a different image. The images now build on a digest, and only the upgrade check moves it, in a PR that must pass the full CI before the new base is used. The mirror refreshes every six hours and triggers that upgrade check when it moves a tag past its pin, so the pins follow Docker's rebuilds - and the dhi.io apt repository moving with them - within hours rather than drift behind it. Every pinned and mirrored digest keeps a tag of its own, so a pinned image never becomes untagged. The hardened images keep stock Debian's apt sources beside dhi.io, and apt took whichever offered the higher version, mixing Debian builds into an image whose dependencies were built by Docker. dhi.io is now preferred whenever it publishes the package. Generated-by: Claude Opus 5 * Let dhi.io's package versions win over the image's own Docker renumbered its builds ("1.0.8-6+dhi2" became "1.0.8-6+deb13u0+dhi2", which sorts lower) and its apt repository moved to the new numbers before its images did. Every package depending on a renumbered build - bzip2, libffi-dev, libgpg-error-dev among them - is then uninstallable, because apt will not replace the image's higher-numbered copy with the repository's lower-numbered one, and the CI image build fails (docker-hardened-images/catalog#689). Every package in the image comes from dhi.io, so letting its repository decide their versions is safe, and it keeps the build working through such a renumbering. Generated-by: Claude Opus 5 * Move the base images to Docker's current Python patch releases Docker stops rebuilding a Python patch release once it publishes the next, so the 3.11.17, 3.12.15 and 3.13.16 images still carry the old package numbering that the dhi.io apt repository has moved past, and installing packages on them fails (docker-hardened-images/catalog#689). Docker fixed it in the images of the current patch releases. Generated with the Python part of the upgrade check, which also pins the new images to the digests the mirror serves for them. Generated-by: Claude Opus 5 * Compare the registry host exactly in the mirror test Generated-by: Claude Opus 5 * Lower the dhi.io apt pin below 1000 so dependencies can resolve At priority 1001 the Package:* dhi.io preference forces dhi.io's build even as a downgrade, so apt keeps dhi.io's libpq5 17.11 and postgresql-client-18 (which needs libpq5 >= 18.6 from PGDG) cannot be installed. Below 1000 the preference still favours dhi.io for the packages it publishes but lets apt take a newer version from another repository to satisfy a dependency. The forced "downgrade" the >1000 priority handled no longer arises now the base image is pinned to a digest CI has passed on. * Rank the PostgreSQL apt repository above the dhi.io preference install_postgres adds the PGDG repository, but the hardened image's Package:* dhi.io preference outranks Debian's default, so apt kept dhi.io's libpq and postgresql-client-18 (which needs a newer libpq5 than dhi.io carries) failed with held broken packages. Pinning the PostgreSQL origin above the dhi.io preference lets apt take libpq from PGDG to satisfy the client. * Use US spelling favors to pass the docs spellcheck The docker-stack docs spellcheck rejects the British spelling favours in build.rst; use the US spelling there and in the matching install-script comments. --------- Co-authored-by: Rahul Vats <43964496+vatsrahul1001@users.noreply.github.com> (cherry picked from commit 4843535) Co-authored-by: Jarek Potiuk <jarek@potiuk.com>
…#76026) The YAML Dag importer was covered by unit tests only. Nothing ran a YAML Dag through a real Dag processor, and the `run:` plus queue-routing path had no coverage at all. Add a `yaml_dag` e2e mode whose Dag exercises every task body the importer supports: provider operators and a sensor driving S3 on LocalStack, a `run:` task routed by its queue to the Go coordinator, and a bodiless task that becomes an EmptyOperator. The Go example bundle gains the handler behind that one code task. (cherry picked from commit 4064747) Co-authored-by: Claude <noreply@anthropic.com>
…rm (#75991) (#75994) * UI: Stop Recent Configurations flashing on the trigger form The section decided to hide itself only once its runs had arrived, so every time the trigger form opened it first drew an empty, disabled select and then either filled it or removed it. The query does not start until the modal opens, which reports as pending rather than loading, so neither flag on its own tells you the runs are in hand. * UI: Lay out Recent Configurations like the rest of the trigger form Every other row in the form names itself in a column down the left and puts its control to the right. This one announced itself in small type above a control that ran the full width, so the eye had to change track in the middle of the form. * UI: Offer recent configurations when they come from cache Runs stay fresh for five minutes, so reopening the trigger form inside that window serves them from cache without fetching. Asking the query whether it had fetched since mounting read that as "not ready" and hid configurations that were already in hand. Nothing needs asking. The options are built from the runs alone, so they are empty both before the runs arrive and when none of them carried a config, and in either case there is nothing to show. --------- (cherry picked from commit 212fe09) Co-authored-by: Brent Bovenzi <brent@astronomer.io> Co-authored-by: Claude <noreply@anthropic.com>
…s flat (#76016) (#76029) * Apply gc.freeze before forking serve_logs in the triggerer The triggerer forks serve_logs from its main process. Under the fork start method the child shares the parent's pages copy-on-write; a later full GC writes to every object's header and splits those shared pages into private copies, inflating anonymous memory with no new allocation. Freeze the GC before the fork and unfreeze right after, mirroring the executors (#58365), the Dag processor manager (#60505), and the Celery worker (#62212). No-op under forkserver/spawn. * Trim the gc.freeze comment to the non-obvious point * Keep the GC frozen after forking serve_logs (per review) Unfreezing right after the fork let the main process's next full GC split the COW-shared pages, cancelling the benefit. Freeze and stay frozen under the fork start method only (forks happen once, like the Dag processor manager); skip the freeze entirely for forkserver/spawn. * Move the gc.freeze to before the trigger-runner fork Freezing before the serve_logs fork was too early -- the heavy object graph is built afterward, so the pages shared with the later trigger-runner fork were still split by the next full GC and memory still stepped (~246->431 MB PSS). Freeze right before the runner's bare fork instead, gated on not _should_use_exec() (no COW sharing when the child execs), and stay frozen. Reverts the serve_logs change; measured flat (~245->246 MB PSS). * Freeze the GC before the serve_logs fork too, not only the runner fork Ephraim's 4-way PSS measurement on 3.4.0a4 (fork start method, GC forced in all three triggerer processes) showed the runner-fork freeze alone still steps (245 -> 341 MB): serve_logs is forked earlier, shares the heap, and its own full GC copies it. Freezing before the serve_logs fork keeps it flat and the runner inherits the frozen generation. Keep the runner-fork freeze for --skip-serve-logs and forkserver, where nothing is frozen beforehand. --------- (cherry picked from commit 5af4c5b) Co-authored-by: Rahul Vats <43964496+vatsrahul1001@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
…76030) * Honor Airflow logging levels in TypeScript SDK * Harden TS SDK log level filtering - Keep the helper method's level when args carry a `level` field, so a non-string value can no longer crash `send()`. - Filter levels outside LogLevel as INFO instead of letting them bypass the threshold. - Filter by the channel's own name, matching the `[name]` event prefix, rather than a caller-supplied `logger` field. - Report an invalid `logging_level` instead of silently using INFO. - Drop FATAL so accepted names match structlog's NAME_TO_LEVEL. - Extract namespace_levels parsing and resolve each channel's threshold once at construction. * Restore FATAL log level alias in TS SDK Airflow's configure_logging adds a `fatal` alias to NAME_TO_LEVEL before parsing logging_level and namespace_levels, so Python accepts FATAL. Removing it made the TS SDK reject a setting the Python side honors. * Address review: rename threshold to logLevel and trim comments --------- (cherry picked from commit 5cc2413) Co-authored-by: Shivam Rastogi <6463385+shivaam@users.noreply.github.com> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
vatsrahul1001
requested review from
Lee-W,
XD-DENG,
amoghrajesh,
ashb,
bbovenzi,
bolkedebruin,
bugraoz93,
choo121600,
dheerajturaga,
dstandish,
ephraimbuddy,
gopidesupavan,
guan404ming,
henry3260,
hussein-awala,
jason810496,
kaxil,
o-nikolas,
pierrejeambrun,
rawwar,
ryanahamilton,
shubhamraj-git,
uranusjr and
vatsrahul1001
as code owners
October 30, 2026 17:39
vincbeck
deleted the
dependabot/npm_and_yarn/airflow-core/src/airflow/api_fastapi/auth/managers/simple/ui/v3-4-test/3-4-auth-ui-package-updates-bcb2736d9f
branch
October 30, 2026 19:02
Contributor
|
Hi maintainer, this PR was merged without a milestone set.
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Bumps the 3-4-auth-ui-package-updates group with 8 updates in the /airflow-core/src/airflow/api_fastapi/auth/managers/simple/ui directory:
5.104.45.105.07.90.07.91.08.71.28.72.08.71.28.72.08.71.28.72.05.12.15.13.08.71.28.72.08.3.48.3.5Updates
@tanstack/react-queryfrom 5.104.4 to 5.105.0Release notes
Sourced from @tanstack/react-query's releases.
... (truncated)
Changelog
Sourced from @tanstack/react-query's changelog.
Commits
5cc606eci: Version Packages (#12301)14cc330style(packages): write durations in 'count * unit * 1000' order (#12382)d7c0418chore(react-query/{useQuery,useInfiniteQuery}): remove the unused '@eslint-re...aa3e26bchore(react-query/{HydrationBoundary,utils}): explain why 'react-hooks-js/ref...b2801aatest(react-query/useMutation): assert that the mutation settles in the cache ...43636c4test(react-query/useMutation): wait for the mutation to settle after unmount ...1eed9d9chore(*): explain why 'vitest-js/valid-expect' is disabled for the 'expectTyp...6bdeb13test(*/useQuery): rename the 'throwOnError' callback parameter to 'err' to av...86b9f20test(*/useMutationState): rename the built 'mutation' to 'existingMutation' t...d09972btest(*): rename the 'queryKey' test helper to 'createKey' since it creates ke...Updates
react-hook-formfrom 7.90.0 to 7.91.0Release notes
Sourced from react-hook-form's releases.
... (truncated)
Changelog
Sourced from react-hook-form's changelog.
... (truncated)
Commits
de3c9467.91.0da618cbRevert "🐞 fix(reset): keep mounted Controllers registered so submit still val...e715d44🧴 fix remove optional chaineed8086🐞 fix(useFieldArray): register the array rules again after reset (#13940)fe960d4🐞 fix(setValue): update field array rows when the parent object is set (#13939)0f3e977🐞 fix(createFormControl): keep a newer change's error when an older isValid p...33f65e5🐞 fix(getValidateError): treat an empty message array from validate as valid ...a72bcd7Revert "🐞 fix(objectHasFunction): check own properties to ignore Object.proto...dee9424🐞 fix(reset): release keepIsValid on the next field change or field array op ...76c0b3d🐞 fix(reset): keep mounted Controllers registered so submit still validates t...Updates
@typescript-eslint/eslint-pluginfrom 8.71.2 to 8.72.0Release notes
Sourced from @typescript-eslint/eslint-plugin's releases.
Changelog
Sourced from @typescript-eslint/eslint-plugin's changelog.
Commits
a4c2603chore(release): publish 8.72.0c6eb98cfeat(eslint-plugin): [await-thenable] addallowMixedPromiseArraysoption (#...b382b74fix(type-utils): discriminateAnyType crashes when calling getAwaitedType on a...79edd89fix(eslint-plugin): [require-array-sort-compare] ignore extra this type argum...e7d57ddfix(eslint-plugin): [require-array-sort-compare] check tuples (#13058)2d107aefix(eslint-plugin): use isTypeLiteralType instead of type.isLiteral() to incl...e4695b3feat(eslint-plugin): lazy load rules (#13010)a1a912bfix(eslint-plugin): [no-deprecated] report deprecated properties in object li...1edc975fix(eslint-plugin): [prefer-readonly-parameter-types] check where allowed typ...61cb700chore: fix alleslint-plugin-internal/no-multiple-lines-of-errors(#12893)Updates
@typescript-eslint/parserfrom 8.71.2 to 8.72.0Release notes
Sourced from @typescript-eslint/parser's releases.
Changelog
Sourced from @typescript-eslint/parser's changelog.
Commits
a4c2603chore(release): publish 8.72.0Updates
@typescript-eslint/utilsfrom 8.71.2 to 8.72.0Release notes
Sourced from @typescript-eslint/utils's releases.
Changelog
Sourced from @typescript-eslint/utils's changelog.
Commits
a4c2603chore(release): publish 8.72.0a1a912bfix(eslint-plugin): [no-deprecated] report deprecated properties in object li...Updates
eslint-plugin-perfectionistfrom 5.12.1 to 5.13.0Release notes
Sourced from eslint-plugin-perfectionist's releases.
Changelog
Sourced from eslint-plugin-perfectionist's changelog.
Commits
9ee9e5bbuild: publish v5.13.0d898b96docs: fix broken examples and reversed alias descriptions640b3e2docs: add playground8c713e1fix(sort-maps): reject newline options combined with partitioning by newlinesf1665c1fix: support lists of locales in natural sorting11429bfchore: update dependencies7951342fix: validate setting values and allow partitioning imports by newlines02a10f5ci: add sort-constructor-parameters to allowed scopes4d06954perf: skip elements whose options cannot report errors4d542f6feat: add sort-constructor-parameters ruleUpdates
typescript-eslintfrom 8.71.2 to 8.72.0Release notes
Sourced from typescript-eslint's releases.
Changelog
Sourced from typescript-eslint's changelog.
Commits
a4c2603chore(release): publish 8.72.0Updates
vitefrom 8.3.4 to 8.3.5Release notes
Sourced from vite's releases.
Changelog
Sourced from vite's changelog.