Undefined `start_year`/`end_year` should mean "no limit", rather than first/last milestone year
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 42/100
Research direction
No source files or tests are named. Start by tracing how each process stores its milestone-year vector and how empty start_year/end_year values become bounds, then read related issue #845. Done means an empty lower or upper bound imposes no corresponding installation-year limit without materializing every year.
Written by the indexing model from the issue text.
Description
If a user leaves the start_year for a process empty, I think they would reasonably expect that there should be no lower limit on the installation year for that process.
However, currently, if the user tried to add an existing asset from before the first milestone year, they would get an error like Process GASDRV does not operate in the year 2010
This is because we automatically use the first milestone year (in this case 2020) as the start_year. To fix this, the user would have to manually set the start year to 2010 or earlier (although it's not really clear from the error message that this is what they have to do).
Ideally, if the user leaves start_year empty we should allow existing assets from before the first milestone year, with no lower limit. (I guess it's probably unlikely that users will want to install something in 400BC, so we could reasonably impose a lower limit if we need!)
Practically, I'm not sure how we do this because we store a vec of years for each process rather than a range, and we don't want to have to store all years in the vec, but something to think about.
Linking #845 as well as these may be related
- Dominant language
- Rust
- Stars
- 8
- Forks
- 5
- Avg merge
- 11h 31m
- Merged PRs (30d)
- 33
Contributor guide
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 EnergySystemsModellingLab/MUSE2
-
bug documentation
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
EnergySystemsModellingLab/MUSE2#1367 · 1 comment ·
-
Remove the `ironing out iteration 0` prefix from debug files when the ironing out loop is turned off Openmuse xiii question
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
EnergySystemsModellingLab/MUSE2#1221 ·
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
EnergySystemsModellingLab/MUSE2#1554 ·
-
bug
EnergySystemsModellingLab/MUSE2#1541 · 2 comments · 1 assignee ·
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
EnergySystemsModellingLab/MUSE2#1526 ·
All issues in EnergySystemsModellingLab/MUSE2
Similar issues
-
bug github_actions
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
registrystack/registry-stack#1393 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
longbridge/gpui-kit#3223 ·
-
bug engine
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
rocky-data/rocky#2181 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
oasisprotocol/oasis-sdk#2523 ·
-
[indexer] [QA] Add a focused test for the new NonRetryableError / assertSocketAlive() behavior. Openbot:ai-assisted component:indexer QA-roadmap status:untriaged
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
midnightntwrk/midnight-indexer#1557 ·