• Home
  • Features
  • Pricing
  • Docs
  • Announcements
  • Sign In

bleedingdeacons / register / 31266799496
50%

Build:
DEFAULT BRANCH: main
Ran 08 Aug 2026 04:23PM UTC
Jobs 1
Files 22
Run time 1min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst

08 Aug 2026 04:22PM UTC coverage: 91.768%. Remained the same
31266799496

push

github

web-flow
fix: make nullability honest across the app (121 -> 77) (#28)

All five nullable-reference codes to zero, 0 errors. Verified by per-code diff:
CS8600 9, CS8602 2, CS8603 3, CS8604 2 and CS8618 28 all go to zero, and no
other code changed count in either direction.

The 28 CS8618 needed three different answers depending on what the type is:

  * Plain DTOs get `required`. WelcomeEmail (9 properties) is constructed
    exactly once, in AttendanceService, with an object initialiser that
    already sets all nine. MeetingContact (3) has no construction site at all
    today, so `required` costs nothing now and forces the issue when someone
    does build one.

  * The EF entity gets defaults, not `required`. QueuedEmail is materialised
    by EF from context.QueuedEmails, and its four non-nullable strings already
    carry [Required] for the database's benefit, so `= string.Empty` keeps both
    construction paths working without adding a compile-time contract to a
    persisted type.

  * Events become nullable, because an event with no subscribers *is* null.
    Nine of them across ClearableEntry, MaskedRevealLabel and EmailService.
    IEmailService's declarations move too — the interface and implementation
    should agree, and CircuitStateChanged in that same file was already
    nullable, so this brings the other three in line with existing practice.

Fields that genuinely may be unset (DatabaseBackupViewModel's selected file,
GroupSelectionViewModel's criteria, EmailStatusPage's designer-path viewmodel)
are declared nullable rather than papered over with `= null!`.

Two knock-on effects the first build surfaced:

  * Making an [ObservableProperty] field nullable changes the signature of the
    generated On<Name>Changed partial, so the hand-written implementations
    needed `?` too (CS8611, two sites).

  * GroupSelectionViewModel.LoadDataAsync dereferenced Criteria three times.
    It now returns early when Criteria is unset — which is correct, s... (continued)

680 of 741 relevant lines covered (91.77%)

5.28 hits per line

Jobs
ID Job ID Ran Files Coverage
1 31266799496.1 08 Aug 2026 04:23PM UTC 22
91.77
GitHub Action Run
Source Files on build 31266799496
  • Tree
  • List 22
  • Changed 0
  • Source Changed 0
  • Coverage Changed 0
Coverage ∆ File Lines Relevant Covered Missed Hits/Line
  • Back to Repo
  • Github Actions Build #31266799496
  • 180a1ecb on github
  • Prev Build on main (#31264001079)
  • Next Build on main (#31271697893)
STATUS · Troubleshooting · Open an Issue · Sales · Support · CAREERS · ENTERPRISE · START FREE TRIAL · SCHEDULE DEMO
ANNOUNCEMENTS · TWITTER · TOS & SLA · Supported CI Services · What's a CI service? · Automated Testing

© 2026 Coveralls, Inc