Skip to content

chore(deps): Bump Avalonia.Controls.DataGrid and 2 others - #95

Closed
dependabot[bot] wants to merge 1 commit into
mainfrom
dependabot/nuget/Daqifi.Avalonia/minor-and-patch-257a6d395d
Closed

chore(deps): Bump Avalonia.Controls.DataGrid and 2 others#95
dependabot[bot] wants to merge 1 commit into
mainfrom
dependabot/nuget/Daqifi.Avalonia/minor-and-patch-257a6d395d

Conversation

@dependabot

@dependabot dependabot Bot commented on behalf of github Aug 10, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

Updated Avalonia.Controls.DataGrid from 12.1.0 to 12.1.2.

Release notes

Sourced from Avalonia.Controls.DataGrid's releases.

12.1.2

What's Changed

Full Changelog: AvaloniaUI/Avalonia.Controls.DataGrid@12.1.0...12.1.2

Commits viewable in compare view.

Updated Daqifi.Core from 1.3.0 to 1.5.0.

Release notes

Sourced from Daqifi.Core's releases.

1.5.0

Verified end-to-end against a DAQiFi Nyquist (firmware 3.7.2) over USB: serial discovery, connect + populated init, 100 Hz streaming, SD card list/storage, and LAN chip info all pass. Full unit suite green (2,853 tests) on net9.0 and net10.0.

Highlights

  • Cancellable async surface on IStreamingDevice, IAsyncDisposable on IDevice — connecting, streaming, and tearing down a device can now all be cancelled and awaited properly, instead of blocking or relying on manual cleanup. This makes it much easier to build responsive apps on top of Core — a UI can cancel a stuck connect attempt or cleanly dispose a device without extra plumbing. Note for anyone implementing these interfaces directly outside this repo: you'll need to add the new async members, DisposeAsync, and the 9 calibration confirmation members described below — sync-only callers are unaffected. (#​460, #​469)
  • Calibration and voltage-precision commands now confirm they actually landed — previously, if a device refused one of these commands, Core reported success anyway, because it never checked. That could leave a device silently uncalibrated with no way to tell. These commands now read the device's own error queue back and raise a clear error if the device didn't accept it, so a failure surfaces instead of hiding. (#​455)
  • WiFi firmware updates are more resilient — Core now handles the full update sequence itself instead of leaving apps to work around gaps: it powers the WiFi module on before an update so the update mode actually takes effect, recovers the module automatically if a flash fails partway through (instead of leaving it unreachable until a power cycle), and no longer triggers an unnecessary reflash just because it couldn't reach GitHub to check the latest version. (part of #​269 — #​443, #​444, #​445, #​434)

Fixes

  • Streaming rate limits are re-checked after enabling more channels, so a rate that was valid for a small channel set can no longer stay in effect once it exceeds what the larger channel set actually supports. (#​472)
  • Devices are now recognized as the same physical unit regardless of whether their serial number was reported in decimal or hex — previously a device could appear as two different devices depending on which form was seen first. (#​471)
  • The MCP server no longer reports made-up PWM duty-cycle/frequency values for state nobody actually commanded — it now reports "unknown" until a real command has been sent, instead of a plausible-looking guess. (#​470)
  • Serial device discovery no longer loses track of a device just because a prior discovery attempt timed out or was cancelled partway through. (#​454)
  • Fixed a defect where a device's binary status data could be misinterpreted as a text message and discarded. (part of #​268 — #​457)

Internal

  • SCPI wire strings single-sourced through ScpiMessageProducer. (#​468)
  • Dead-API sweep: TextMessage, SdCardBusyException, abandoned simulator docs. (#​467)
  • DaqifiStreamingDevice continues splitting into focused collaborators — channel/DIO/PWM/analog-output control, status-frame channel mapping, stream frame decode, connect/disconnect serialization, device administration, raw-command session interpretation, the live-sample async stream, session snapshot/restore, and USB stream-interface routing. (part of #​344 — #​432, #​433, #​435, #​436, #​437, #​439, #​440, #​441, #​442)
  • Shared ScaleRawAnalogValues helper extracted for SD card parsing. (#​466)
  • CI now runs on merge_group so a merge queue can gate main. (#​459)
  • Command history documented as oldest-first, not newest-first. (part of #​344 — #​452)
  • Assorted test hardening: bounded live-stream device test awaits, wall-clock-tight tests no longer race a stalled CI runner, WiFi update SCPI sequence expectations reconciled, canceled-settle case guarded against a persisted network config. (#​453, #​458, #​456, #​451)

Full Changelog: daqifi/daqifi-core@v1.4.0...v1.5.0

1.4.0

Verified end-to-end against a DAQiFi Nyquist (firmware 3.7.2) over USB: serial discovery, connect + populated init, 100 Hz streaming, SD card list/storage, and LAN chip info all pass. Full unit suite green (2,531 tests) on net9.0 and net10.0.

Highlights

  • Auto-reconnect and streaming session resume — opt in, and a device that drops mid-capture reconnects and picks the stream back up instead of leaving you to rebuild it. (#​379, #​418)
  • Cancellable async connect/disconnect and IAsyncDisposable — connect and teardown now honor a CancellationToken, and devices can be await using'd. (#​341, #​416)
  • Per-device operation serialization — concurrent callers no longer read each other's replies; every exchange takes its turn on the device. (#​342, #​421)
  • SD card operations over WiFi — list, storage, download, and logging control now work over the TCP transport, not just USB. (#​327, #​420)

Features

  • DeviceCapabilities merges the device's own live capability document, so what a device reports wins over compiled-in assumptions. (#​390, #​404)
  • Managed WINC serial-bridge protocol plus a read-only WiFi module inspector. (part of #​271, #​423)
  • Producer write failures surface through a SendFailed event instead of vanishing. (#​413)
  • An opt-in connect that attaches to a device without disturbing a stream already running on it. (#​385, #​414)

Reliability & fixes

  • A physically dropped serial or TCP connection is detected, making ConnectionStatus.Lost reachable. (#​403)
  • Core's connectivity guards throw a typed DeviceNotConnectedException. (#​395, #​402)
  • Four downstream workarounds retired: SD stall typing, empty-transfer guard, ResetAll semantics, and the Verifying overload. (#​398, #​405)
  • SD download is bounded, so a wedged card can't hang the call or ignore cancellation. (#​399, #​401)
  • A timed-out SD LIST is no longer reported as an empty card. (#​396, #​400)
  • The SD bus switch and the SD→LAN restore both run inside the exchange lock. (#​406, #​407, #​417)
  • Background failures are visible, and the last silent read-loop spin is gone. (#​377, #​378, #​394, #​415)
  • Analog IsEnabled tracks the device — protobuf field 22 is parsed. (#​409, #​411)
  • Serial connect failures are named for what they are instead of all reading as access denials. (#​424, #​427)
  • Firmware's malformed first stream frame is no longer broadcast to consumers. (#​425, #​428)
  • SD log parsing uses the device's own timestamp clock. (#​426, #​429)
  • The MCP server rejects over-max sample rates instead of silently clamping them. (#​412)

Internal

  • DaqifiStreamingDevice and FirmwareUpdateService split into focused collaborators. (part of #​344, #​419, #​422)
  • WINC abandoned-open tests are deterministic rather than timing-based. (#​430)
  • Dependency bump. (#​393)

Full Changelog: daqifi/daqifi-core@v1.3.0...v1.4.0

Commits viewable in compare view.

Updated SQLitePCLRaw.bundle_e_sqlite3 from 3.0.4 to 3.0.5.

Release notes

Sourced from SQLitePCLRaw.bundle_e_sqlite3's releases.

3.0.5

Update the lib dependency for SQLitePCLRaw.bundle_e_sqlite3 to package ID SQLite version 3.53.4.

Commits viewable in compare view.

@dependabot dependabot Bot added .NET Pull requests that update .NET code dependencies Pull requests that update a dependency file labels Aug 10, 2026
@dependabot dependabot Bot mentioned this pull request Aug 10, 2026
Closed
@dependabot
chore(deps): Bump Avalonia.Controls.DataGrid and 2 others
39697fa 
Bumps Avalonia.Controls.DataGrid from 12.1.0 to 12.1.2
Bumps Daqifi.Core from 1.3.0 to 1.5.0
Bumps SQLitePCLRaw.bundle_e_sqlite3 from 3.0.4 to 3.0.5

---
updated-dependencies:
- dependency-name: Avalonia.Controls.DataGrid
  dependency-version: 12.1.2
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: minor-and-patch
- dependency-name: Daqifi.Core
  dependency-version: 1.5.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: minor-and-patch
- dependency-name: SQLitePCLRaw.bundle_e_sqlite3
  dependency-version: 3.0.5
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: minor-and-patch
...

Signed-off-by: dependabot[bot] <support@github.com>
@dependabot
dependabot Bot force-pushed the dependabot/nuget/Daqifi.Avalonia/minor-and-patch-257a6d395d branch from c5bd28b to 39697fa Compare August 14, 2026 23:32
@dependabot @github

dependabot Bot commented on behalf of github Aug 17, 2026

Copy link
Copy Markdown
Contributor Author

Looks like these dependencies are updatable in another way, so this is no longer needed.

@dependabot dependabot Bot closed this Aug 17, 2026
@dependabot
dependabot Bot deleted the dependabot/nuget/Daqifi.Avalonia/minor-and-patch-257a6d395d branch August 17, 2026 13:17
@tylerkron tylerkron mentioned this pull request Aug 31, 2026
Merged
tylerkron added a commit that referenced this pull request Aug 31, 2026
@tylerkron @claude
fix(ci): count lock files as evidence a claimed bump landed
fe4eaed 
check_dependabot_claims.py only looked at .csproj PackageReference pins,
so a transitive-only update — a security bump to something no csproj
names — would have failed the check. That is the most costly PR to block
on a false positive.

Lock files are safe to trust here: in #130 the lock file recorded
Daqifi.Core at 1.3.0 right alongside the csproj, because the bump landed
nowhere. Re-verified against the repo's real Dependabot PRs — still
passes #93/#95/#96, still fails #130 on all ten unapplied claims.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
tylerkron added a commit that referenced this pull request Aug 31, 2026
@tylerkron @claude
fix(ci): check a claimed bump in every project that pins it, not just…
582c9af 
… one

Qodo, correctly: accepting a claim because SOME manifest reached the new
version lets a grouped multi-directory PR move one head and leave another
stale. Avalonia.Fonts.Inter is pinned by three projects here, so that is a
real input shape, not a hypothetical.

Now every project pinning the package must be at the claimed version —
scoped to the `directories` Dependabot actually manages, read from
dependabot.yml at check time. The scope matters in both directions: the
iOS head is not managed, so its pins drift on purpose and must not fail a
PR that could never have touched them; and if the list grows later, the
check grows with it. An unreadable config is exit 2, never a silently
widened scope.

Qodo's suggested fix — carrying per-claim directory context out of the PR
body — does not work: Dependabot dedupes a package across directories, so
a grouped body states each bump once regardless of how many directories
it touches.

Lock files stay evidence-only, never grounds for failure. A legitimate
single-directory PR leaves the other directories' lock files recording
the old transitive version (#93 changed only Daqifi.Avalonia/), so
failing on that would reject good PRs.

Re-verified against the repo's real Dependabot PRs: passes #93/#95/#96,
fails #130 on all ten unapplied claims, and the scope correctly excludes
the iOS head. Self-test grows to 28 cases, including Qodo's exact
scenario.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
tylerkron added a commit that referenced this pull request Aug 31, 2026
@tylerkron @claude
chore(deps): make Daqifi.Core updates visible instead of silently ski…
c544a54 
…pped (#137)

* chore(deps): make Daqifi.Core updates visible instead of silently skipped

Daqifi.Core sat at 1.3.0 for five weeks while four releases shipped, and
nothing said so. The assumption was that Dependabot had never opened a PR
for it. It had — twice — but never in a way anyone could see:

  #93  bumped Core 1.3.0 -> 1.4.0, titled "the minor-and-patch group with
       3 updates"; Core appears nowhere in the title.
  #95  superseded it with 1.3.0 -> 1.5.0, titled after Avalonia.
  08-17 Dependabot auto-closed #95 and opened no replacement. Two weeks of
       silence while 1.6.0 and 1.7.0 shipped.
  #130 announced Core 1.3.0 -> 1.7.0 in its body and never touched the
       csproj. Ten of its fourteen announced updates are missing from the
       diff.

The NU1605 downgrade theory does not explain it: Core 1.4.0/1.5.0/1.6.0
all depend on System.IO.Ports 10.0.10, exactly what was pinned. Only 1.7.0
raised the floor.

Three guards, one per failure:

- Daqifi.Core is excluded from the minor-and-patch group, so it always
  gets its own "Bump Daqifi.Core from X to Y" PR — visible in a PR list,
  and not droppable from a group whose other members moved.
- check_dependabot_claims.py fails a Dependabot PR whose body claims a
  bump its manifests do not show. Verified against this repo's history:
  passes #93/#95/#96, fails #130 on all ten unapplied claims.
- check_core_drift.py compares the pin against nuget.org weekly and files
  a rolling issue, independent of Dependabot having done anything at all.

Both guards ship with self-tests, and build.yml now runs every
.github/scripts self-test on each push and PR — without that, these two
would only be exercised on a Dependabot PR or on a Monday.

.github/dependency-updates/README.md records the investigation.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* fix(ci): count lock files as evidence a claimed bump landed

check_dependabot_claims.py only looked at .csproj PackageReference pins,
so a transitive-only update — a security bump to something no csproj
names — would have failed the check. That is the most costly PR to block
on a false positive.

Lock files are safe to trust here: in #130 the lock file recorded
Daqifi.Core at 1.3.0 right alongside the csproj, because the bump landed
nowhere. Re-verified against the repo's real Dependabot PRs — still
passes #93/#95/#96, still fails #130 on all ten unapplied claims.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* fix(ci): check a claimed bump in every project that pins it, not just one

Qodo, correctly: accepting a claim because SOME manifest reached the new
version lets a grouped multi-directory PR move one head and leave another
stale. Avalonia.Fonts.Inter is pinned by three projects here, so that is a
real input shape, not a hypothetical.

Now every project pinning the package must be at the claimed version —
scoped to the `directories` Dependabot actually manages, read from
dependabot.yml at check time. The scope matters in both directions: the
iOS head is not managed, so its pins drift on purpose and must not fail a
PR that could never have touched them; and if the list grows later, the
check grows with it. An unreadable config is exit 2, never a silently
widened scope.

Qodo's suggested fix — carrying per-claim directory context out of the PR
body — does not work: Dependabot dedupes a package across directories, so
a grouped body states each bump once regardless of how many directories
it touches.

Lock files stay evidence-only, never grounds for failure. A legitimate
single-directory PR leaves the other directories' lock files recording
the old transitive version (#93 changed only Daqifi.Avalonia/), so
failing on that would reject good PRs.

Re-verified against the repo's real Dependabot PRs: passes #93/#95/#96,
fails #130 on all ten unapplied claims, and the scope correctly excludes
the iOS head. Self-test grows to 28 cases, including Qodo's exact
scenario.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* fix(ci): measure Core drift from the oldest pin, not the first one read

Same class of bug Qodo found in the sibling guard: check_core_drift.py
returned the first manifest pinning Daqifi.Core and stopped. Two projects
pinning it at different versions would report whichever happened to be
read first — which could report "up to date" while another project sat
four releases back.

Drift is now measured from the oldest pin, with disagreeing pins called
out explicitly, and the verdict no longer depends on manifest order.
Today only Daqifi.Avalonia.csproj pins Core, so this changes nothing
about the current repo; it stops the guard going quiet the moment that
is no longer true.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* style(ci): early-continue the lock-file walk instead of a wide ternary

Drops a 92-character line to within the file's own width; no behaviour
change.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* fix(ci): keep every Daqifi.Core reference, not one per project file

Qodo, correctly: pinned_versions keyed by manifest path, so a second
reference to the package in the SAME project overwrote the first.
Conditional ItemGroups per framework or RID are an ordinary MSBuild
shape, and since drift is measured from the oldest pin, a newer
reference could hide an older one and report the repo current while a
conditional pin sat four releases back.

It now returns every (version, manifest) pair. Ties resolve by manifest
name rather than filesystem order, so the reported file is stable across
runs.

check_dependabot_claims.py does not share this: it keeps a set of
versions per package per file, so a duplicate reference at a stale
version already fails the claim.

Tests cover both orderings of a doubly-referenced project — the verdict
must not depend on which reference is read last.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

dependencies Pull requests that update a dependency file .NET Pull requests that update .NET code

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

0 participants