Skip to content

[Quality-2][High] Reject bets at exact deadline boundaries deterministically #1396

Description

@greatest0fallt1me

Summary

Implement Reject bets at exact deadline boundaries deterministically as a production-ready change in Predictify-org/predictify-contracts.

Why this matters

The implementation must be deterministic and reviewable so normal operation and adverse conditions do not cause silent data loss, inconsistent state, security regressions, or an unrecoverable user experience. This issue specifically requires state-transition and authorization invariants, including replay and boundary behavior.

Scope

Trace the relevant entry points, state model, and failure paths; implement the smallest complete design; preserve public interfaces unless a compatibility plan is included; and document important invariants in code.

Priority

High

Acceptance criteria

  • The intended behavior is deterministic for valid, invalid, duplicate, and boundary-case inputs.
  • Authorization, validation, and state-transition invariants remain enforced.
  • Retries, partial failure, and concurrent execution cannot produce an unsafe or inconsistent result.
  • Focused tests cover success, rejection, boundary, and regression scenarios.
  • Existing callers remain compatible, or the PR includes a tested migration path.
  • Relevant logs, metrics, or user-visible errors make failures diagnosable without exposing sensitive data.

Validation

Run focused tests and repository CI checks with evidence for normal operation, invalid input, retries, concurrency or timing boundaries, and failure recovery where applicable.

Non-goals

  • Typo-only, formatting-only, documentation-only, or cosmetic changes.
  • Unrelated refactors, dependency upgrades, or broad rewrites.
  • Removing safeguards or weakening validation to make tests pass.

Contributor application

Before coding, describe affected modules, proposed state/invariant changes, test strategy, compatibility considerations, and an estimate. Wait for assignment before starting implementation.

PR requirements

Use a feature branch and include Closes #<issue-number>. Address every criterion, map criteria to code and tests, explain security and failure-mode handling, and ensure CI passes.

Quality review

A maintainer will assess correctness, completeness, test depth, compatibility, observability, and adverse-case handling. A substantive implementation is required; merge or CI status alone does not guarantee reward eligibility.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

Stellar WaveStellar Wave Program issue

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions