[PM-4128] Remove nullability of Send.Data and Send.Keys

[harr1424]

🎟️ Tracking

https://bitwarden.atlassian.net/browse/PM-4128

📔 Objective

While MSSQL already enforces that Send.Data and Send.Key are not nullable, the Send entity has been updated to reflect this and EF migration scripts have been generated.

Note that as opposed to adding the required keyword to the now non-nullable properties, they are assigned a default initial value of empty string, this is ephemeral as the server will assign the key sent in the client request and assemble the JSON data from non-null components of the same request.

See related PR #7212

[github-actions]

Checkmarx One – Scan Summary & Details – 21c3b113-4ef2-4cce-95f2-5e1402088a44

Great job! No new security vulnerabilities introduced in this pull request

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 61.88%. Comparing base (5aae028) to head (68d26f0).
⚠️ Report is 16 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #7266      +/-   ##
==========================================
+ Coverage   57.62%   61.88%   +4.26%     
==========================================
  Files        2033     2043      +10     
  Lines       89619    89868     +249     
  Branches     7978     7991      +13     
==========================================
+ Hits        51642    55616    +3974     
+ Misses      36117    32312    -3805     
- Partials     1860     1940      +80     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[rkac-bw]

Missing NULL backfill before NOT NULL constraint in all 3 EF migrations
Migration would fail if any not null, is this a concern?

[harr1424]

Missing NULL backfill before NOT NULL constraint in all 3 EF migrations Migration would fail if any not null, is this a concern?

@rkac-bw This migration assumes that there are no NULL values in columns Data or Key based upon how Send objects are created:

server/src/Core/Tools/Entities/Send.cs

Lines 46 to 64 in 8310ea1

	/// <summary>
	/// Stores data containing or pointing to the transmitted secret. JSON.
	/// </summary>
	/// <note>
	/// Must be nullable due to several database column configuration.
	/// The application and all other databases assume this is not nullable.
	/// Tech debt ticket: PM-4128
	/// </note>
	public string? Data { get; set; }
	/// <summary>
	/// Stores the data's encryption key. Encrypted.
	/// </summary>
	/// <note>
	/// Must be nullable due to MySql database column configuration.
	/// The application and all other databases assume this is not nullable.
	/// Tech debt ticket: PM-4128
	/// </note>
	public string? Key { get; set; }

It would be prudent to query production data for any unexpected NULL values, unless you prefer the backfill occurs regardless.

[rkac-bw]

Missing NULL backfill before NOT NULL constraint in all 3 EF migrations Migration would fail if any not null, is this a concern?

@rkac-bw This migration assumes that there are no NULL values in columns Data or Key based upon how Send objects are created:

server/src/Core/Tools/Entities/Send.cs

Lines 46 to 64 in 8310ea1

	/// <summary>
	/// Stores data containing or pointing to the transmitted secret. JSON.
	/// </summary>
	/// <note>
	/// Must be nullable due to several database column configuration.
	/// The application and all other databases assume this is not nullable.
	/// Tech debt ticket: PM-4128
	/// </note>
	public string? Data { get; set; }
	/// <summary>
	/// Stores the data's encryption key. Encrypted.
	/// </summary>
	/// <note>
	/// Must be nullable due to MySql database column configuration.
	/// The application and all other databases assume this is not nullable.
	/// Tech debt ticket: PM-4128
	/// </note>
	public string? Key { get; set; }

It would be prudent to query production data for any unexpected NULL values, unless you prefer the backfill occurs regardless.

Cloud is fine — SQL Server has enforced NOT NULL on these columns since the table was created.

For self-hosted instances on MySQL/MariaDB, PostgreSQL, or SQLite, we'd recommend a defensive backfill to
protect against any unexpected NULLs. You can just edit the generated migration files and add
migrationBuilder.Sql() calls at the top of each Up() method:

MySQL/MariaDB:
migrationBuilder.Sql("UPDATE Send SET Key = '' WHERE Key IS NULL;");
migrationBuilder.Sql("UPDATE Send SET Data = '' WHERE Data IS NULL;");

PostgreSQL:
migrationBuilder.Sql("UPDATE "Send" SET "Key" = '' WHERE "Key" IS NULL;");
migrationBuilder.Sql("UPDATE "Send" SET "Data" = '' WHERE "Data" IS NULL;");

SQLite:
migrationBuilder.Sql("UPDATE "Send" SET "Key" = '' WHERE "Key" IS NULL;");
migrationBuilder.Sql("UPDATE "Send" SET "Data" = '' WHERE "Data" IS NULL;");

No-op if no NULLs exist, prevents a migration failure if they do.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
53.7% Duplication on New Code

See analysis details on SonarQube Cloud

[rkac-bw]

lgtm