[WIP] Add offline queue rejection hook feature

[Copilot]

Thanks for asking me to work on this. I will get started on it and keep this PR's description up to date as I form a plan and make progress.

Original prompt

Apply the offline queue rejection hook feature to fork repo ombagal777/node-redis on master. Implement optional client option offlineQueueRejectionHook that fires when commands are rejected because disableOfflineQueue is true. Payload includes command, argsLength, clientId, timestamp, reason "offline-queue-disabled". Hook errors must be swallowed. Add deterministic tests and test.sh for base/new modes with JUnit output. Update types/docs as needed. Ignore commit hash; work on fork master.

The following is the prior conversation context from the user's chat exploration (may be truncated):

User: Now u have the context of project mars, its guidelines, example.
Now while creating this mars problem before submit we have to pass through the test checks.

Here as u can see on pictures.

First set of checks test the problem description and test.
Then verify build, verify tests, verify solution, environment quality, verify flakiness, task quality, solution quality, description quality.
And agents runs where 10 nova + 2 orion agent runs to solve the problem.

Assistant: Understood. The screenshots confirm the Mars pipeline: initial submission checks (repo, description/tests, Dockerfile, solution patch), then quality checks (build/tests/solution/env/flakiness/task/solution/description), followed by rollouts (Nova + Orion) and AI review. I’m ready for the next details about the checks or to help design a problem that passes them.

User: Now lets select project in which we should work on. We will choose feature implementation.

Here are two repos 'yup', 'node-redis', 'node-resque'.

Analyze them and tell me which repos and suggest me problem suitable for project mars (make sure to check issues of that repo, as per mars guidelines).

We will choose one repo and most suitable problem as per mars to work on that.

Assistant: Based on the open-issue snapshots, jquense/yup is the best Mars candidate, with redis/node-redis as a close second and actionhero/node-resque least suitable.

✅ Recommendation: jquense/yup

Why it’s best:

• Issues are clear, testable, and deterministic (ideal for Mars).
• The codebase is TS-heavy and mature.
• Several open bugs map cleanly to focused behavioral specs.

Best Mars‑fit issue suggestions:

1. “URL validation fails with localhost”

   • Issue: URL validation fails with localhost jquense/yup#2312
   • Deterministic, isolated, easy to test with schema validation.
   • Can be extended with edge cases (localhost + ports + paths) for Mars difficulty.

2. “InferType optional fields not optional”

   • Issue: yup InferType works wrong with optional fields jquense/yup#2313
   • Type-level correctness, good for TS-heavy repo.
   • Requires multiple files and tests; fits Mars scope.

3. “Standard schema always async”

   • Issue: Standard schema always async jquense/yup#2318
   • More complex, behavioral; could yield a strong Mars challenge.

---

⚠️ Redis/node-redis (Second choice)

Why less ideal:
Open issues are large, environment‑dependent (cluster failures, Azure/K8s), hard to reproduce deterministically.
These are risky for Mars because tests may require complex integration setups.

---

❌ actionhero/node-resque (Least suitable)

Why:
Many issues are stale (2021–2022), repo appears less active → might fail “recent activity” or reviewer expectations. Also more mixed JS/TS and older architecture.

---

Next Step

If you agree, I’ll proceed with jquense/yup and draft one Mars‑style problem (title + description + proposed tests + expected patch scope).

Would you like to use:

• URL validation fails with localhost, or
• InferType optional field bug, or
• Standard schema async behavior?

User: As per mars guidelines its not always that we will be working on PR issues open.
instead we can create our own without posting the issue.

like feature implementation.
Analyze the Redis/node-redis and actionhero/node-resque to implement feature without focusing on issue publicly listed. instead we can create our own PR of feature implemenation as per suitable for mars guidelines.
Which problem should align with complexity and difficulty of mars.
also should be testable.

Assistant: Recommendation: choose redis/node-redis for a Mars feature task. It’s more active, has stronger test infrastructure, and has enough surface area to design a deterministic, non‑trivial feature that hits the Mars difficulty band. actionhero/node-resque is older and less active; you risk failing “recent activity” or quality checks.

Below are feature ideas not tied to public issues, designed to be deterministic, testable, and Mars‑appropriate.

---

✅ Best pick: redis/node-redis

Feature idea A: Configurable command timeout policies

Goal: allow per‑command timeout overrides and global policy for retries.
Why Mars‑fit: touches client config, command pipeline, timers, and error mapping.

Behavior sketch

• New client option: `co...

This pull request was created from Copilot chat.