chore: enabling strictNullChecks in back-end sources

[ericleponner]

Description:

Changes below enable strict-null-checks and strictBindingCallApply flags in back-end tsconfig.json.

Related issue(s):

Fixes #3316

[swirlds-automation]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 99.92%. Comparing base (5cd0f09) to head (1e36ef6).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3338      +/-   ##
==========================================
- Coverage   99.98%   99.92%   -0.06%     
==========================================
  Files         213      213              
  Lines        6699     6725      +26     
  Branches     1209     1229      +20     
==========================================
+ Hits         6698     6720      +22     
- Misses          1        5       +4     

Files with missing lines	Coverage Δ
back-end/apps/api/src/auth/auth.service.ts	100.00% <100.00%> (ø)
...k-end/apps/api/src/auth/strategies/jwt.strategy.ts	100.00% <ø> (ø)
...d/apps/api/src/auth/strategies/otp-jwt.strategy.ts	100.00% <ø> (ø)
...s/api/src/auth/strategies/otp-verified.strategy.ts	100.00% <ø> (ø)
...-end/apps/api/src/guards/frontend-version.guard.ts	100.00% <100.00%> (ø)
...ack-end/apps/api/src/guards/jwt-blacklist.guard.ts	100.00% <100.00%> (ø)
...on-preferences/notification-preferences.service.ts	100.00% <100.00%> (ø)
...fication-receiver/notification-receiver.service.ts	98.71% <100.00%> (-1.29%)	⬇️
...pi/src/transactions/approvers/approvers.service.ts	100.00% <100.00%> (ø)
...ransactions/dto/update-transaction-approver.dto.ts	100.00% <100.00%> (ø)
... and 15 more

... and 1 file with indirect coverage changes

🚀 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.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[Copilot]

Pull request overview

Copilot reviewed 105 out of 105 changed files in this pull request and generated 2 comments.

Suppressed comments (6)

back-end/apps/notifications/src/receiver/receiver.service.ts:1

• transaction.creatorKeyis accessed as non-null, but the function comment says a deleted creator key will not be included (i.e., it can be null/undefined). This can throw at runtime. Use optional chaining (and filter out missing creatorId) or explicitly throw if a creator key is required for this flow, and adjust downstream uses ofcreatorId!` accordingly.
  back-end/libs/common/src/transaction-signature/account-cache.service.ts:1
• encodedKey is a bytea/Buffer | null field, but this code writes [] when accountData.key is null. This will store the wrong type and may fail at runtime or serialize incorrectly. Use null (or undefined if you intend to omit updating the column) instead of an empty array.
  back-end/libs/common/src/execute/execute.service.ts:1
• Using undefined in a TypeORM .set() commonly means “do not update this column”. If transactionStatusCode is null and you intend to clear statusCode, this will leave the previous DB value untouched (stale status code). Prefer setting statusCode to null when you want to clear it, or build the .set() object conditionally to match the intended semantics.
  back-end/apps/api/src/users/users.service.ts:1
• When reactivating a soft-deleted user, deletedAt should be explicitly cleared. Setting it to undefined typically results in “no update” (keeping the user deleted) depending on how updateUser() persists. Use deletedAt: null to reliably undelete the user (and keep tests aligned with the actual persistence semantics).
  back-end/libs/common/src/transaction-signature/transaction-signature.service.ts:1
• New error message is missing punctuation and uses inconsistent quoting, which makes it harder to search/standardize in logs. Consider using a consistent message format (e.g., No fee payer account id.) and (optionally) a domain-specific error type if callers need to distinguish configuration/data errors from internal errors.
  back-end/apps/api/src/auth/auth.service.ts:125
• Falling back to '' when OTP_SECRET is not configured can create a predictable OTP secret, which may allow OTP verification to succeed under a misconfiguration. Instead, reject verification when the secret is missing (e.g., throw UnauthorizedException or a configuration error) rather than verifying against an empty secret.

    const secret = this.getOtpSecret(user.email) ?? '';

    const { valid } = await otplib.verify({
      token,
      secret,

[ericleponner]

Fixed.

[ericleponner]

Type of transactionTypeFilter is TransactionType[] : so optional chaining is useless.