Skip to content

Make network timeout and retry analysis context-aware #4

Description

@devkyato

Problem

RLY105, RLY106, and RLY113 intentionally use conservative local heuristics. They can miss a timeout configured through a nearby object method or warn when a bounded helper applies the deadline indirectly.

Proposed direction

Track simple timeout, retry-count, deadline, and backoff state through local variables and direct call chains without turning the core into a compiler dependency.

Acceptance criteria

  • recognise common settimeout, request keyword timeout, and Arduino/ESP client timeout patterns
  • distinguish attempt limits, elapsed-time deadlines, and capped backoff
  • propagate only high-confidence facts; label other conclusions as uncertain
  • include exact evidence and inferred call paths
  • add positive and negative fixtures for Python, MicroPython, Arduino, and ESP32
  • preserve deterministic ordering and bounded memory use

Activity

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    analyzerParser and static-analysis engineenhancementNew feature or requesttiming-modelTiming contracts, impact estimates, and timelines

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions