utils.openPage not passing query Params

UPDATE: Definately a ReTool issue - I have not made a new release in a few days, and it's not working on the release from a few days ago, where as yesterday, it was working on that same release absolutely fine.

Bug with routing. On a button on a list view, I am executing the following click event:

utils.openPage(
"scheme_dashboard",
{
queryParams: {
scheme_id: item.scheme_id_uuid
}
}
)

when I hover over item.scheme_id_uuid it appears correctly, but clicking it does not add the ?scheme_id=XXX into the URL. On the console, I can see an intermittent warning about routing being 'POP blocked'... This was working absolutely fine until now, and for some reason now, the openPage command does not add the ?scheme_id=XX to it. Any ideas? This has completely broken my app!

3 Likes

Hi there, this has completely broken all our applications using multipage as we pass many query params between all our pages.

It was working yesterday afternoon but stopped working when checking this morning.

const selected_vehicle = table2.selectedSourceRow;

// if its a custodian vehicle open the vehicle_view page
if (selected_vehicle.vehicle_id != null || selected_vehicle.everyday_vehicle_id != null) {
  utils.openPage('vehicle_view', {
      queryParams: {
        id: selected_vehicle.vehicle_id ? selected_vehicle.vehicle_id : selected_vehicle.everyday_vehicle_id,
        application_id: url.searchParams.id,
        customer_id: url.searchParams.customer_id
      }
    });
  return;
}

// if its an external vehicle open the external_vehicle_view page
if (selected_vehicle.external_vehicle_id != null) {
  utils.openPage('external_vehicle_view', {
    queryParams: {
      id: selected_vehicle.external_vehicle_id,
      application_id: url.searchParams.id,
      customer_id: url.searchParams.customer_id
    }
  });
  return;
}

None of the queryParams are passed and accordingly, our application completely fails to work.

And the problem is, all you have is this forum. Retool is not a cheap piece of software, and when something goes wrong, there's no one to ring despite this clearly being a Retool issue. This has broken our app!

1 Like

I thought I was going crazy, but turns out, I'm not the only one seeing this issue. Yep, can't pass query params in utils.openPage. This should be considered P0 bug.

Hitting the same thing with our company app. I had to do a quick workaround of using utils.openUrl to unblock us.

Note: This also impacts utils.openApp, but only if you pass in the pageName parameter. Once that parameter is passed, the queryParams just get axed.

Hey all! Thanks for bringing this to our attention. We are on it -- will update soon with timeline for fix.

5 Likes

This should be fixed now on cloud! Please let us know if you are still having this issue

2 Likes

Do you know what version this was fixed in? I am still seeing the broken behavior. I believe we are on cloud. The version number shown after refreshing is "v3.116.0-a499470 (Build 212161)"

Update: can anyone confirm that it is fixed for them? And if so could you post what version number you are seeing it on?

This should be fixed in 3.116—do you mind posting/sending a screen recording or an app JSON here or to ibork@retool.com?

1 Like

If anyone else is experiencing this issue, it's because we added a new way to pass data between pages with this util. If you had an event handler that called utils.openPage, please modify it from:

utils.openPage('newPage', {queryParams: {'nice': 'dog'}})

to

utils.openPage('newPage', {passDataWith: 'urlParams', queryParams: {'nice': 'dog'}})

I'll push a fix out that defaults to passing data with query params that should come out next week! Sorry for the inconvenience everyone

1 Like

I can confirm that this works with passDataWith: 'urlParams' added in. THANK YOU for the quick turn around!

This is not working for me when run from a success handler script.

create_new_data_element.trigger({
additionalScope: {},
onSuccess: function (data) {
console.log("hello1");
console.log(data);
console.log("hello2");
console.log(data.newDataElement.id);
console.log("hello3");
utils.openPage('data_element_details', {passDataWith: 'queryParams', queryParams: {'id': "1"}});
},
onFailure: function (error) {}
});

The URL that it redirects to has ID but the id is empty, despite me passing a constant "1" to it.

1 Like

Ah so sorry there's a typo, it should be urlParams instead of queryParams!
I edited my previous comment to reflect this

2 Likes

Why does this work,

utils.openPage('data_element_details', {
      "passDataWith": 'urlParams', 
      "queryParams": {
        "nice":"dog"
      }
    });

but this doesn't?

create_new_data_element.trigger({ 
  additionalScope: {}, 
  onSuccess: function (data) { 
    utils.openPage('data_element_details', {
      "passDataWith": 'urlParams', 
      "queryParams": {
        "nice":"dog"
      }
    }); 
  },
  onFailure: function (error) {} 
});

in the same script block, I just changed the former to the latter, and it the query succeeds, but the utils.openPage doesn't work.

Hey @bbeasleyAtZscaler - I just tested the example you shared above without any issues. What kind of query is create_new_data_element and how are you verifying that it's running successfully?

@Darren it's an API query. I know it's successful becuase a green pop-up at the bottom right shows it ran successfuly, and in the network tab of chrome web developer tools I see that the api request went through successfully.

Nevermind, got it working. I had an extra success handler on the query that I had mistakenly forgotten to delete which I had put there for debugging. Thanks devs and community for the resolution.

3 Likes

Glad to hear it, @bbeasleyAtZscaler! I did the exact same thing earlier. :sweat_smile: At the suggestion of another community member, we actually have a small UI improvement coming that will show you at a glance exactly how many event handlers have been defined for the query that you're looking at.

To everybody else that flagged this issue - including @FloodMatt, @Mentioum, and @larsendaniel_nectar - thank you for taking such quick action and for for your patience as we worked on a resolution today. We're aware that the forum may not feel like the ideal medium for reporting outages or breaking changes, but we do keep a close eye on posts as they come in! That said, we are thinking about how we can streamline that reporting process even further. :+1:

Don't hesitate to let us know if you have any additional feedback and I hope so see you around the Community!

2 Likes

This makes a bigger issue @Darren , that Retool allow their dev to make changes to key functions, with potentially app breaking consequences, and we just have to flag it as an issue. Why was this just rolled out without consultation? @Isabella_Borkovic stated that they changed the way they call that function, but changes were made, knowing it would break many apps. How has that been allowed to happen, and what processes will retool put in place in future to prevent this happening again?

3 Likes

Hey @FloodMatt - I appreciate the feedback and the reminder that our customers and community really do rely on these things to just work. That's something we try to keep front of mind and, as such, it's important to highlight the fact that this particular change was intended to be fully backwards compatible. The full fix to make it so should go live later this week. Outside of critical security issues, we wouldn't knowingly push out an update that breaks existing functionality.

Not to say that there isn't a lesson here. Our primary takeaway is that test coverage needs to improve, especially as it pertains to multipage. This is something that the team is actively addressing in order to prevent future feature development from causing similar regressions.

I very much mean it when I say that I'm thankful that you and the wider community are so quick to report these kind of issues, but also recognize that it's obviously better if you don't have to!

7 Likes