Filtering not working

[rytsh]

When I try to filter with javascript it is not saving my filter code and always return true.

This is very core feature and not usable for newer versions. Could you please check it?

[weeco]

Could you please provide more information on how to replicate it? I'm able to use javascript filters just fine. What is a "newer version"? Not working, means you are seeing more messages than you expected to pass the filter?

Could you share some screenshots which may explain a few things

[rytsh]

I saw problem starting when I use the base path, is there any good documentation about basepath setting, it is for me trying some combination of configuration.

I am accepting /kafka/ after that I am striping prefix /kafka than I am adding X-Forwarded-Prefix: "/kafka/" header.
This was working in 2.5.2 version and half working in 2.8.x versions.
Half mean you can still read messages some functions working but some of them not like filtering.

[paul-green]

Filters are not saved at all since 2.8.3 - I verified they work in 2.8.2 but not since (checked 3.0.0)

Simply create any filter - e.g 'return false' and save - all messages are shown but none should be.

Then edit the filter and you'll see 'return true' is the filter still - so not being saved

[weeco]

@paul-green I cannot reproduce this, see this video (this is V3).

ss-FREksbFF.mp4

[paul-green]

Hi @weeco
I'm using the docker images btw.

This is docker.redpanda.com/redpandadata/console:v2.8.2 - works OK

docker-v2.8.2-working-filters-small.mp4

This is docker.redpanda.com/redpandadata/console:v3.0.0 - does not save the filter

docker-v3.0.0-broken-filters-small.mp4

Thanks
Paul

[rytsh]

@paul-green , are you also using base_path setting? I have same issue I was thinking using base_path caused it.

[paul-green]

@rytsh actually yes - I'm running it under a path not / ;

<base href="/redpanda/"/>

So v2.8.2 works with this setup but v2.8.3 onwards does not.

Thanks

[MediaMarco]

I think it was the file frontend/src/config.ts in revision d675089 which introduced this bug.

// Ensure yaml workers are being loaded locally as well
  loader.init().then(async () => {
    window.MonacoEnvironment = {
      getWorkerUrl(_, label: string): string {
        switch (label) {
          case 'editorWorkerService': {
            return `${window.location.origin}/static/js/editor.worker.js`;
          }
          case 'typescript': {
            return `${window.location.origin}/static/js/ts.worker.js`;
          }
          default: {
            return `${window.location.origin}/static/js/${label}.worker.js`;
          }
        }
      },
    };
});

window.location.origin does not seem to take the baseUrl into account. The former code was different and did use the base url by referencing config.assetsPath:

// Ensure yaml workers are being loaded locally as well
  loader.init().then(async (monaco) => {
    window.MonacoEnvironment = {
      baseUrl: `${config.assetsPath}/static/js/vendor/monaco/package/min`,

      getWorker(moduleId, label) {
        console.debug(`window.MonacoEnvironment.getWorker looking for moduleId ${moduleId} label ${label}`);
        switch (label) {
          case 'editorWorkerService':
            return new Worker(new URL('monaco-editor/esm/vs/editor/editor.worker', import.meta.url));
          case 'yaml':
            // return new yamlWorker();
            return new Worker(new URL('monaco-yaml/yaml.worker', import.meta.url));

          default:
            throw new Error(`Unknown label ${label}`);
        }
      },
    };

    configureMonacoYaml(monaco, monacoYamlOptions);
  });

So the calls to ts.worker.js and editor.worker.js after submitting a filter through the form answer with 404 because they're missing the baseUrl suffix (attached a screenshot from the dev console):

[weeco]

Thank you all for the additional hints & debugging. This is helpful. I promise we'll be looking at the URL rewrite issues very soon. I haven't had time to do so yet, but I'll internally raise the awareness for this issue.

If any of you are Redpanda customers, please raise it via the usual support channels.

[jaxtonw]

Do we have any updates on this issue and plans to include a fix in a release soon? The latest version, 3.2.1, still has this issue. This filter functionality is quite critical to my workflow and my team is needing to downgrade due to this bug.