Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

controller.challengeService.removeChallenge unable to remove global challenges #437

Closed
Burn-the-w1tch opened this issue Apr 23, 2024 · 7 comments · Fixed by #458
Closed
Labels
bug Something isn't working!

Comments

@Burn-the-w1tch
Copy link

Describe the bug
controller.challengeService.removeChallenge is unable to remove global challenges. Returns the error: TypeError: Cannot read properties of undefined (reading 'get')
To reproduce
Put this in a script to repro, this is to remove a challenge from the escalation track: controller.challengeService.removeChallenge("7c4e7906-ad19-46c0-96f4-4fc301a562b4", "h3")

@Burn-the-w1tch Burn-the-w1tch added the bug Something isn't working! label Apr 23, 2024
@RDIL
Copy link
Member

RDIL commented Apr 24, 2024

Global challenges are special and aren't handled by the challenge system - they are a config.

@Burn-the-w1tch
Copy link
Author

Is there any way to handle them via plugin?

@RDIL
Copy link
Member

RDIL commented Apr 24, 2024

You can modify the list by accessingcontroller.configManager.configs.GlobalChallenges

@Burn-the-w1tch
Copy link
Author

Gotcha, thanks.

@Burn-the-w1tch
Copy link
Author

Actually, this doesn't work as 7c4e7906-ad19-46c0-96f4-4fc301a562b4 is not in that config.
It is only in contractdata/GLOBAL
/_ESCALATION_CHALLENGES.json

@Yanrishatum
Copy link
Contributor

This bug is caused by global challenge ParentLocationId being "", while they are registered under GLOBAL_* virtual location id.

For example: When _ESCALATION_CHALLENGES.json is being registered by Peacock, it will register their groups challenges inside a GLOBAL_ESCALATION_CHALLENGES "location". However all those challenges have a ParentLocationId value set to "", and that value is being used to determine the location id that holds the global challenge group during removeChallenge call.

Additionally, this also affects reBatchIntoSwitchedData: If challenge group first registered challenge is a global challenge, it will return an empty challenge list. (This bug prevents ability to register global-only challenge packs)

Refs:

@Yanrishatum
Copy link
Contributor

Solutions:

  • Patch each global challenge to match ParentLocationId to its group location ID in the .json files. (Not a good one)
  • Assign ParentLocationId when registering challenges. (Also not a good one)
  • Use same approach as inGroup field and assign inLocation field and use that for location lookbacks. This one seem most reasonable, however it will make it impossible to make user-made global-visible challenge groups (like Classics)

My general proposal:

  1. Introduce inLocation field.
  2. Introduce an API when registering groups to make them globally visible.
    • Can be done by extra argument for registerGroup, a custom field of group definition or separate markGlobal method or along the lines.
    • During getGroupByIdLoc check if request group is global, and return merged challenge group, as with Classics.

I can prepare a PR with fix and global marker myself, as long as consensus on API is met.

Yanrishatum added a commit to Yanrishatum/Peacock that referenced this issue May 11, 2024
@Yanrishatum Yanrishatum mentioned this issue May 11, 2024
2 tasks
AnthonyFuller pushed a commit that referenced this issue May 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working!
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants