Logs of type "ferrt" are not synced on CloudWatch

[ca-simone-chiorazzo]

We are experiencing strange behaviour with the CloudWatch extension.

Even if we've flagged all the log types, we do not receive the logs of type "ferrt". Every other log types are dumped on CloudWatch in the correct way.

Do you have any suggestions on what could be the issue?

[meichstedt]

I've just set up this extension and am encountering the same.

ferrt is contained in the config but my understanding is that all logs should be exported when nothing in particular is selected.

This is pretty serious as I have no idea what else might be missing.

Alright if I'm not mistaken the issue is that this package depends on [email protected] while only version 1.3.10 added the knowledge about ferrt.

[ca-simone-chiorazzo]

Hi @meichstedt ,

thanks for checking it out! I saw you've already changed the fix version in a commit, when do you expect to release a new version of auth0-logs-to-provider?

Also, how do you suggest recovering events of type "ferrt" that have not been synced by the extension?

[meichstedt]

@ca-simone-chiorazzo yeah I wanted to verify that this actually helps but haven't gotten to that yet. I am completely new to this codebase, I just happen to use the extension, ran into the same problem. Let's see whether some upstream maintainer chimes in to help :)

[meichstedt]

@ca-simone-chiorazzo seems my hunch is correct: The config in this repo is used to create a LogsApiStream which will be initialized with a logType list which will

• be empty of neither logTypes or a logLevel are defined
• contains only the logTypes matching a given logLevel known by the log-extension-tools library
• or contains all logTypes explicitly specified (e.g. by this library)

No idea why people chose to go that route: every time a new log type is introduced, the associated logs won't be exported unless someone adds them to the list in the extension-tools and in this extension. The proper™️ way to do such configuration
– IMHO – would be to export all logs by default, and have the config opt-in to filter them. It's a really really bad design choice to filter logs which are unknown, especially when the library isn't actively maintained.

The good news is, if I'm not mistaken, that selecting all logTypes in the config should also export ferrt since the explicit list will win over what's known to extension-tools. As per the question wether these can be exported after the fact: I'd check and see whether configuring a Checkpoint ID of log to start from will re-process them. This should work but will re-process all other logs as well, unfortunately.

[stale]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?