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

fix: Handle multiple external portals as siblings #2217

Merged
merged 1 commit into from
Oct 2, 2023

Conversation

DafyddLlyr
Copy link
Contributor

@DafyddLlyr DafyddLlyr commented Sep 15, 2023

What does this PR do?

When was this bug introduced?

It appears to have been there since dataMerged() was written as far as I can tell which is a little surprising - I don't have total confidence in this but it's my best guess.

Why not moved dataMerged() to a shared location like planx-core?

We could do this, but there's not real need to - if more flow management / logic goes there then sure, but for now we can continue to live with the duplication here I think.

Test flows

ob[id] = {
...node,
type: TYPES.InternalPortal,
data: { text: slug },
};
} else if (node.type === TYPES.ExternalPortal && !ob[node.data.flowId]) {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's a little rearranging / renaming here but breaking up this condition is what's fixed the bug. As is, this flattens the first external portal it hits, but skips subsequent ones.

@github-actions
Copy link

github-actions bot commented Sep 15, 2023

Removed vultr server and associated DNS entries

@DafyddLlyr DafyddLlyr force-pushed the dp/external-portal-bug branch from d4059a5 to 45edb4c Compare September 15, 2023 15:29
@DafyddLlyr
Copy link
Contributor Author

@DafyddLlyr DafyddLlyr marked this pull request as ready for review September 17, 2023 15:51
@DafyddLlyr DafyddLlyr requested a review from a team September 17, 2023 15:51
Copy link
Member

@jessicamcinchak jessicamcinchak left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for this fix & tests - pizza working as expected for me!

Still a bit hung up on where we've introduced this (not totally convinced beginning of dataMerged because flows published a couple months ago are ok?)

One half-baked thought while sifting through changes is perhaps that the newish FlowGraph type from planx-core is being misused somewhere to type unpublished flows (which it actually can't handle because it doesn't account for data.flowId in a Node) when it should only be used to type published flows? Just noticing the type right now, and haven't confirmed if any actual nodes were getting dropped/overwritten on sort or order, but just a thought! It's such a strange one.

if (nodeId === "_root" && Object.keys(ob).length > 0) {
const isExternalPortalRoot = nodeId === "_root" && Object.keys(ob).length > 0;
const isExternalPortal = node.type === TYPES.ExternalPortal;
const isMerged = ob[node.data?.flowId];
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: is isNotMerged a more clear name here since node.data?.flowId indicates it's still an external portal reference, not flattened representation of individual nodes?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So here ob is the returned item (the flattened flow). If ob[node.data?.flowId] == true then the flow has already been flattened and ob[example-uuid-of-portal] exists. Does that make sense?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TBH I think some of the language here is a little fuzzy around merging / flattening

@DafyddLlyr
Copy link
Contributor Author

One half-baked thought while sifting through changes is perhaps that the newish FlowGraph type from planx-core is being misused somewhere to type unpublished flows (which it actually can't handle because it doesn't account for data.flowId in a Node) when it should only be used to type published flows? Just noticing the type right now, and haven't confirmed if any actual nodes were getting dropped/overwritten on sort or order, but just a thought! It's such a strange one.

I actually think something along these lines is more likely but I've also not been able to prove anything / work it out 🤔

@DafyddLlyr
Copy link
Contributor Author

DafyddLlyr commented Sep 18, 2023

Thanks for the review! As anything graph related is high impact I'll request PO testing on the Pizza before merging.

@DafyddLlyr DafyddLlyr added the UAT (User Agent Testing) actively being tested before deployment label Sep 18, 2023
@DafyddLlyr
Copy link
Contributor Author

@DafyddLlyr DafyddLlyr merged commit 6f1aca1 into main Oct 2, 2023
@DafyddLlyr DafyddLlyr deleted the dp/external-portal-bug branch October 2, 2023 11:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
UAT (User Agent Testing) actively being tested before deployment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants