fix: reject expiration timestamp 0 and accept far-future timestamps in getEventExpiration()

[Priyanshubhartistm]

Description

getEventExpiration() in src/utils/event.ts used Math.log10(expirationTime) < 10 as a bounds check on the NIP-40 expiration tag. This has two bugs:

• Math.log10(0) === -Infinity, which is < 10, so an expiration of 0 (Unix epoch) was accepted as valid.
• Any safe-integer timestamp past year 2287 (> 9,999,999,999) failed the < 10 check and was silently discarded, treated as "no expiration."

Replaced the check with expirationTime > 0, which accepts any positive safe integer and rejects non-positive values, with no arbitrary digit-count ceiling.

Related Issue

Closes#707

Motivation and Context

An expiration of 0 should never be treated as a valid future expiration, and a relay shouldn't silently ignore legitimate (if far-future) expiration timestamps just because they cross an arbitrary digit-count boundary.

How Has This Been Tested?

• Added two unit tests in test/unit/utils/event.spec.ts under the existing NIP-40 > getEventExpiration suite:
  • expiration: '0' → undefined
  • expiration: '10000000000' (year 2287+) → returned as-is
• Ran pnpm run test:unit (1395 passing) and pnpm run test:cli (73 passing)
• Ran pnpm run lint, pnpm run check:deps, pnpm run build,
  pnpm run verify:cli:build, pnpm run cover:unit — all pass.

Screenshots (if appropriate):

N/A — pure logic fix, no UI/API surface change.

Types of changes

• Non-functional change (docs, style, minor refactor)
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my code changes.
• I added a changeset, or this is docs-only and I added an empty changeset.
• All new and existing tests passed.

[changeset-bot]

🦋 Changeset detected

Latest commit: 25a9eed

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
nostream	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[coveralls]

coverage: 69.785% (+0.02%) from 69.77% — Priyanshubhartistm:fix/event-expiration-validation-allows-zero into cameri:main

[Anshumancanrock]

@Priyanshubhartistm To be clear this isn't on you. 2038–2286 already fails on main for the same reason, the old log10 < 10 check let those through too.

@cameri i think your ms-scale concern still holds, just at a lower ceiling.

[Anshumancanrock]

@Priyanshubhartistm Flip the two far-future tests to expect undefined and add one for 2147483647 and all good.

Actual year-9999 support needs expires_at moved to bigint. I can open a seperate issue for it.

[Priyanshubhartistm]

@Anshumancanrock , thanks for tracing it through to the column type pushed a fix that caps at 2147483647 to match the actual expires_at int4 column, and flipped/added the tests accordingly. Agreed the year-9999 case is a separate bigint migration; happy to have that tracked as its own issue rather than bundled here

[cameri]

@Anshumancanrock please re-review

[Anshumancanrock]

LGTM

[cameri]

@Priyanshubhartistm feel free to merge
@Anshumancanrock thank you!