Fetching a transceiver's part info shouldn't fail silently
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 48/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- rust
- Domain
- networking
Research direction
Start in dpd/src/link.rs around lines 1735-1750, where the transceiver MPN is fetched and later used. Trace the identification failure path and review nearby logging conventions. Done means a failed transceiver identification is recorded instead of passing silently, while preserving the existing reconciliation behavior.
Written by the indexing model from the issue text.
Description
In #104, a customer link failed to come all the way up, because the part-specific overrides for the transceiver's equalization settings were never applied. The underlying issue was likely #111, where we incorrectly marked a transceiver as unsupported too aggressively. Because of that, we failed to fetch the transceiver's MPN, and thus failed to look up the alternate equalization settings.
That's all fine in some sense, because of the link-reconciliation process in Dendrite, that continually tries to apply all the link settings, including these equalization settings. But we have no actual smoking gun proving #111 is the source of the error, because we silently fail in this case. Here, for example:
We're fetching the MPN, and later using it, but none of that code logs the fact that the transceiver couldn't be identified. We should do that, to ensure that this case doesn't pass silently in the future.
- Dominant language
- Rust
- Stars
- 21
- Forks
- 3
- Avg merge
- 8h 29m
- Merged PRs (30d)
- 2
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from oxidecomputer/dendrite
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
oxidecomputer/dendrite#380 ·
Maintainers usually reply within 1 day
-
Difficulty 3/5 1-2 days Newbie friendliness 65/100
oxidecomputer/dendrite#375 ·
Maintainers usually reply within 1 day
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
oxidecomputer/dendrite#369 ·
Maintainers usually reply within 1 day
-
Difficulty 3/5 1-2 days Newbie friendliness 58/100
oxidecomputer/dendrite#368 ·
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 52/100
oxidecomputer/dendrite#359 · 1 comment ·
Maintainers usually reply within 1 day
All issues in oxidecomputer/dendrite
Similar issues
-
backend::vllm diffusion multimodal
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
lambdaclass/ethrex#7329 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 88/100
shadowsocks/shadowsocks-rust#2186 · 1 comment ·
-
C-bug S-awaiting-triage
Difficulty 1/5 Under an hour Newbie friendliness 92/100
juspay/hyperswitch#14479 ·
Maintainers usually reply within 1 day