Changelog

Release history is defined by signed or reviewed v* tags and the corresponding release workflow run. The entries below record what a consumer must know to upgrade; the tag history remains the canonical list of everything that shipped.

Public API or behavior changes must update the relevant module documentation and the package catalog in the same pull request. Breaking changes require a major version and migration guidance.

6.2.1

Fixed

• GrydNotifications no longer requires GrydFiles to start. Since 6.1.0 every host using the module had to register AddGrydFiles — and with it object storage, a ClamAV engine and GrydJobs — and declare the gryd.notification-attachment profile, even if it never sent an e-mail attachment. A host without GrydFiles also failed at runtime: the notifications DbContext, the send handlers and the SMTP provider all depended on GrydFiles services.

  GrydFiles is now optional, as SMTP is:

  • Without AddGrydFiles the host starts with no GrydFiles, GrydStorage or GrydClamAv configuration. In-app, push and e-mail without attachments work as before. A send with AttachmentFileIds is refused when the command arrives with 422 NOTIFICATION_ATTACHMENT_DISABLED_UNPROCESSABLE, and a message that reaches a provider with attachments anyway fails with the same code.
  • With AddGrydFiles nothing changes: the host refuses to start unless the gryd.notification-attachment profile is declared with ScanRequired: true.
  • The presence of GrydFiles is read from the built container, so AddGrydFiles may be called before or after AddGrydNotifications.

  GrydNotifications itself never required GrydJobs or object storage: GrydJobs is used only by the optional GrydNotifications.Scheduling package, and the notifications schema has no reference to the GrydFiles schema. GrydReports still requires GrydFiles and the gryd.report profile, since it stores every report it generates.

  No migration, configuration or code change is needed to upgrade from 6.2.0.

6.1.0 — upgrade notes

6.1.0 introduced GrydFiles (object storage, antivirus and retention for files) and moved the files of GrydReports and GrydNotifications into it. The release was published as a minor version, but it contains the breaking changes below. Upgrading from 6.0.x to any 6.1+ version requires all of them.

Database migrations were regenerated

The Initial migrations of GrydNotifications and GrydReports were regenerated under new ids, and the GrydNotifications DurableNotificationDelivery migration was folded into the new initial one. On a database created by 6.0.x, ApplyGrydNotificationsMigrationsAsync/MigrateAsync sees the new id as pending and fails with relation ... already exists.

Module	6.0.x history	6.1+ history
GrydNotifications	20260328180703_NotificationsInitialMigration, 20260910043154_DurableNotificationDelivery	20260910223916_NotificationsInitialMigration
GrydReports	20260328180720_ReportsInitialMigration	20260910182750_ReportsInitialMigration

The schema change behind the new ids is small, and can be applied by hand before the 6.1+ host starts. Each script takes the database from the 6.0.x schema to the 6.1+ one and records the new migration id; the result was checked against a database created from scratch by 6.1+.

GrydNotifications — attachments used to be bytes in the notifications database and are now references to GrydFiles. 6.0.x attachment rows cannot be converted and are deleted, so let pending e-mails with attachments drain before upgrading.

BEGIN;
DELETE FROM notifications.notification_attachments;
ALTER TABLE notifications.notification_attachments DROP COLUMN "Content";
ALTER TABLE notifications.notification_attachments ADD COLUMN "StoredFileId" uuid NOT NULL;
CREATE INDEX "IX_notification_attachments_StoredFileId"
    ON notifications.notification_attachments ("StoredFileId");
DELETE FROM notifications."__EFMigrationsHistory"
 WHERE "MigrationId" IN ('20260328180703_NotificationsInitialMigration',
                         '20260910043154_DurableNotificationDelivery');
INSERT INTO notifications."__EFMigrationsHistory" ("MigrationId", "ProductVersion")
VALUES ('20260910223916_NotificationsInitialMigration', '10.0.10');
COMMIT;

GrydReports — an execution now points at its file in GrydFiles instead of a storage URI. Reports generated by 6.0.x lose their download. The history table is the one your host configures for the ReportsDbContext; the design-time factory uses reports."__EFMigrationsHistory", as below.

BEGIN;
ALTER TABLE reports.report_executions DROP COLUMN "FileUri";
ALTER TABLE reports.report_executions ADD COLUMN "StoredFileId" uuid NULL;
UPDATE reports."__EFMigrationsHistory"
   SET "MigrationId" = '20260910182750_ReportsInitialMigration', "ProductVersion" = '10.0.10'
 WHERE "MigrationId" = '20260328180720_ReportsInitialMigration';
COMMIT;

A database with nothing worth keeping in these two schemas can instead drop them and let the 6.1+ migrations recreate them.

GrydReports storage moved to GrydFiles

• GrydReportsOptions.LocalStoragePath was removed, together with ReportStorageOptions, the StorageProvider enum and IReportFileStore. There is no local-disk provider any more: files live in the object storage configured for GrydFiles (GrydStorage section).
• A host using GrydReports must register AddGrydObjectStorage, AddGrydFiles and a scan engine (AddGrydFilesClamAv), and declare the gryd.report profile under GrydFiles:Profiles.

Report download contract changed

GET /api/v1/reports/{id}/download no longer streams the file. It answers 200 with a ReportDownloadDto — { "url": "...", "expiresAt": "..." } — and the client fetches the file from url, a short-lived presigned URL, straight from storage. A report whose file is still being verified answers 409 FILE_NOT_AVAILABLE_CONFLICT; ask again a moment later. In the report DTOs, FileUri and DownloadUrl were replaced by StoredFileId.

GrydNotifications attachments moved to GrydFiles

E-mail attachments are no longer bytes in the request: a file is uploaded through POST /files under the gryd.notification-attachment profile and sent by id in AttachmentFileIds (see Email with Attachments). From 6.1.0 to 6.2.0 this made GrydFiles mandatory for every GrydNotifications host; 6.2.1 makes it optional again.