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

Connecting orphan block does not do type checks in correct order #4826

Closed
BeksOmega opened this issue May 12, 2021 · 1 comment
Closed

Connecting orphan block does not do type checks in correct order #4826

BeksOmega opened this issue May 12, 2021 · 1 comment
Labels
component: connection issue: bug Describes why the code or behaviour is wrong

Comments

@BeksOmega
Copy link
Collaborator

Problem

I'm working on type checking generic params for the nominal-connection-checker, and there's an issue where if you insert a generic param block between two other blocks it blows up. In the bellow case I can no longer interact with the workspace because of errors:
blows-up

First of all the insertion marker shouldn't even show up there, but I'll file a separate issue for that. This is a different issue because you also get errors when you connect the block programmatically. In the below case I can't set down the block because of errors:
blows-up-2

I believe this is caused because of how connect_ tries to insert a block X between two blocks A and B:

  1. Checks that X and A are compatible
  2. Disconnects B from A
  3. Tries to connect B to X
    3.1) Checks that B and X are compatible
    3.2) Connects B to X
  4. Connects X to A

So in the case above A is the SelectRandom block, B is the GetterList[Dog] block, and X is the GetterList[T] block. We'll call the other GetterList[Dog] block C.

  1. A is compatible with X because GetterList[T] has a common super type with C's GetterList[Dog] type.
  2. B gets disconnected from A
  3. Tries to connect B to X
    3.1) B is compatible with X because GetterList[Dog] is compatible with the simple generic T
    3.2) Connects B to X
  4. Connects X to A

But step 4 is now erroneous. After step 3.2 the type of X is now GetterList[GetterList[Dog]], which is not compatible with the GetterList[Dog] check from block C.

Solution

I think that what needs to happen is steps 3 and 4 need to be swapped. We should only try to reconnect the orphan after the new parent has been connected, incase the state of the new parent changes when it is connected.

As you can see, if we do this manually, the nominal-connection-checker performs as expected:
manually-disconnect

The other option would be to re-check that X and A are compatible before step 4, but I don't think this makes sense from the perspective of a developer programmatically connecting blocks. If they are trying to programmatically connect X to A, and instead it gets connected to B and then bumped, that doesn't make sense.

Does anyone have thoughts about this before I give it a shot?

@BeksOmega BeksOmega added issue: triage Issues awaiting triage by a Blockly team member issue: bug Describes why the code or behaviour is wrong labels May 12, 2021
@alschmiedt alschmiedt added component: connection and removed issue: triage Issues awaiting triage by a Blockly team member labels Jun 4, 2021
@alschmiedt alschmiedt added this to the Bug Bash Backlog milestone Jun 4, 2021
@BeksOmega BeksOmega mentioned this issue Jun 8, 2021
3 tasks
@alschmiedt
Copy link
Contributor

Fixed in #4880

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component: connection issue: bug Describes why the code or behaviour is wrong
Projects
None yet
Development

No branches or pull requests

2 participants