Skip to content

Conversation

bbrudastyy
Copy link

The basics

The details

Resolves

#2601
Fixes

Proposed Changes

Reason for Changes

Test Coverage

Documentation

Additional Information

@bbrudastyy bbrudastyy requested a review from a team as a code owner September 17, 2025 16:57
@bbrudastyy bbrudastyy requested review from BenHenning and removed request for a team September 17, 2025 16:57
@bbrudastyy
Copy link
Author

I also noticed a complicated code, so I suggest making it easier. I can add a commit in the same PR.
image
I suggest using the usual negation this.setStatements_(state['hasStatements'] !== false);

@BenHenning
Copy link
Contributor

Thanks @bbrudastyy.

To start, we'll want to triage #2601 on our side in case there's additional clarity needed for the issue.

As for the fix, it would be really helpful to understand why this is the best approach for fixing the problem. While it does mitigate the direct error that you encountered, it's not clear if it's actually the correct thing to do. It may be the case, for instance, that statementConnection_ should only ever be a function or null and that this change is hiding a problem happening elsewhere in the plugin or core Blockly.

Could you dig into this a bit more? I think something that would help is identifying what the type actually is (if it isn't a function), why is it that type (e.g. by tracing when it changes), and whether that's correct (i.e. is something assigning it the incorrect value). If it turns out that it can sometimes not be a function, then we probably need to consider all the values it can have and ensure the plugin does the correct thing for each one. All of this may still end up with essentially the solution you landed at, but we can then explain why it's the correct approach by pointing to the places in code which assign it to a non-function value and why it's okay to ignore that in this case (or the code will be updated to account for all the different legitimate values).

@BenHenning BenHenning assigned bbrudastyy and unassigned BenHenning Sep 18, 2025
@BenHenning
Copy link
Contributor

Also: please fill in the PR description fully and correctly. There should be no space before the 'x' for the checkbox, the issue number should go after 'Fixes' (so that GitHub knows to link the issue to the PR), and the other sections should be filled in (I can provide guidance on how to do that if it helps, though I also suspect the investigation I requested in my previous comment will give you a lot of useful details to add to those sections).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants