opentelemetry-go

opentelemetry-go copied to clipboard

Problem Statement

There is a fairly common use-case which users need to do when configuring the (trace/metric/logs) SDK, in which they want to add a resource detector for the environment they are running in. For example, they start with:

// This gives the user resource.Default()
tp := trace.NewTracerProvider(
	trace.WithBatcher(exporter),
)

They want to add a detector. Say, for example, they want to add go.opentelemetry.io/contrib/detectors/gcp.NewDetector(). Many users will do:

res, err := resource.New(ctx,
	resource.WithDetectors(gcp.NewDetector()),
)
// handle err
tp := trace.NewTracerProvider(
	trace.WithBatcher(exporter),
	sdktrace.WithResource(res),
)

This gives them the attributes from the detector they want, but removes the default set. If they want to add the default set back in, they need to do:

res, err := resource.New(ctx,
	resource.WithDetectors(gcp.NewDetector()),
)
// handle err
res, err = resource.Merge(res, resource.Default())
// handle err
tp := trace.NewTracerProvider(
	trace.WithBatcher(exporter),
	sdktrace.WithResource(res),
)

This is quite a bit of extra code just to add a detector, and in my experience has been error prone for users.

Proposed Solution

Add a resource.WithDefault() Option to resource. When used, it is equivalent to merging the resource with the default resource, or adding resource.WithFromEnv() and resource.WithTelemetrySDK() (and adding something similar to the defaultServiceNameDetector). Users would then be able to do:

res, err := resource.New(ctx,
	resource.WithDefault(),
	resource.WithDetectors(gcp.NewDetector()),
)
// handle err
tp := trace.NewTracerProvider(
	trace.WithBatcher(exporter),
	sdktrace.WithResource(res),
)

Alternatives Considered

Add trace/metric/log SDK WithResourceDetector(resource.Detector) option

If the SDK had a WithResourceDetector option, that would be the simplest possible configuration for users (a single option). However, that would mean the error returned by the resource detector, or the merge cannot be returned to users, and would need to be handled by the global error handler. I think this will be surprising to users whose applications occasionally don't have resource attributes attached to telemetry.

Add resource.WithResource(*resource.Resource) option

This would marginally simplify the above by being able to pass resource.WithResource(resource.Default()) to resource.New(). However, it is complex enough i'm not sure users would figure it out. It is unclear if this is worth it.

I have a similar issue, but it only affects the remap shortcut section of the keyboard manager; the single key remaps still operate as per usual. Toggling on/off doesn't work, but restarting the app does.

I also hit that issue regularly. I've remapped Caps to Control via the powertoys, and once in a while I'll come unglued and reset to Caps behaviour, even though the keyboard manager remains enabled. Turning it off and on again does fix it, but obviously it wastes time first screwing up whatever you were trying to do (under the assumption the shortcut would work) then having to go through PowerToys to reset it.

I've not looked but I assume the setting toggles a registry key, and windows updates screw that up (either because PT/KM updates the wrong registry key or because Windows updates suck). If that's the case, maybe PT/KM should read the keys on startup to check that they match the config? Or just unconditionally set them to be sure?

Either way despite being a somewhat rare occurrence it's a pretty frustrating one.

Same for my specific usage: an app has "global shortcuts" and so in this specific app I set alt+u and alt+i, then in powertoys I remap volume up and down to alt+u and alt+i.

Even if powertoys is set to start at startup, I have to manually boot powertoy after each restart of windows and trigger the keyboard function off then on to get it to work. Then I randomly sometimes have to do that off on thing once in a while (not after a restart).

Does anybody have the problem where restarting powertoys doesn't fix it, but specifically restarting keyboard manager does? That's what struck me as weird with my case....

Does anybody have the problem where restarting powertoys doesn't fix it, but specifically restarting keyboard manager does? That's what struck me as weird with my case....

I always reset via the keyboard manager, but since it sometimes breaks on startup I assume I also have that issue. I'll try to restart powertoys next time it occurs to see what happens.

Does anybody have the problem where restarting powertoys doesn't fix it, but specifically restarting keyboard manager does? That's what struck me as weird with my case....

I always reset via the keyboard manager, but since it sometimes breaks on startup I assume I also have that issue. I'll try to restart powertoys next time it occurs to see what happens.

That's exactly my problem: on off does the trick everytime here.

We're trying to fix some of the Keyboard Manager issues soon. Some are opened where keyboard manager stops working after a while. I've tried replicating with the Keyboard Manager settings that were sent, but without success.

@jaimecbernardo

We're trying to fix some of the Keyboard Manager issues soon. Some are opened where keyboard manager stops working after a while. I've tried replicating with the Keyboard Manager settings that were sent, but without success.

Is there any sort of instrumentation in powertoys we could use? (assuming we remember to, I hit the issue again a week or two back but completely forgot to try and restart powertoys to see what that'd do).

There are some logs in the bug report, but they seem to indicate nothing useful for these sort of errors. I think what might be happening is that Windows might be killing the lowlevel keyboard hook we register for some reason (high CPU load?) when it takes a bit more to respond. I wonder if this makes sense.

There are some logs in the bug report, but they seem to indicate nothing useful for these sort of errors. I think what might be happening is that Windows might be killing the lowlevel keyboard hook we register for some reason (high CPU load?) when it takes a bit more to respond. I wonder if this makes sense.

Would delaying the hooking process be a possibility in case windows is unhappy with it happening so early on restart?

It's pretty weird that it's getting called while restarting, though... If you wait for your computer to start everything before pressing a key, does the issue still occur?

Hi,

For me the issue still occurs. After a month or so of being aware of this problem, I've realised in my case that it happens consistently every time I restart.

It's pretty weird that it's getting called while restarting, though... If you wait for your computer to start everything before pressing a key, does the issue still occur?

It does yes.

This happened to me regularly, but I was able to quickly fix it by lock screen with Win+L and re-login. I also tried to downgrade the app to v0.45.0, this issue has never happened again.

Thanks for the suggestion; I tried downgrading to 0.45.0 but sadly it didn't work for me. It's a bit frustrating, the keyboard manager is pretty much the only thing I want powertoys for!

Is this still an issue with the latest version? /needinfo

It has been for me. Although.. yesterday after a reboot it was working right away which is new.. has it been fix in the last update.. maybe. We'll see in the next days.

It has been for me. Although.. yesterday after a reboot it was working right away which is new.. has it been fix in the last update.. maybe. We'll see in the next days.

FWIW for me it's always been somewhat inconsistent.

In my experience it does not work early during startup, but if you let everything settle down it hooks properly. My most common issue is that I'll start the machine, lauch the main applications (including a browser) then as soon as the browser has started C-t to create a new tab. I have Caps remapped to Control, the mapping is not correctly setup yet, and I get nonsense as Windows sends regular (but uppercase) keypresses to the browser window.

Then it can fail seeingly randomly during use, I've not managed to notice any pattern to the latter.

Well it is definitely not fixed: back to the normal behavior, which is turning on and off keyboard manager as needed randomly sometimes many times per day.

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 5 days. It will be closed if no further activity occurs within 5 days of this comment.

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 5 days. It will be closed if no further activity occurs within 5 days of this comment.

I'm keeping this thread alive. I still have issues.

Yeah this is definitely not stale

Ditto, still don't have any hint at what would cause it tho. For me it definitely commonly happens before bootup (which might be attributed to pressing a remapped key between windows boot and KM startup), but it also occurs somewhat randomly long after boot, in which case the KM hook seems to stop for an instant.

Which is frustrating when remapping capslock to control: KM comes unglued, so a press of capslock switches caps mode on, but further presses are correctly converted to control. Thus the computer remains in caps mode. To fix this I have to disable KM, press capslock (to toggle it off), and re-enable KM.

Same here. Under high load keyboard manager stops remapping my Caps lock to Ctrl. I have to open it, switch it off, toggle caps lock and switch it on again. Incredibly annoying.

Since 2022! Why this is not fixed? Keymanager doesn't work unless I restart the whole app! Please FIX this! Win 11 + PowerToys latest versions.

Is this issue still relevant in v0.73? /needinfo

Is this issue still relevant in v0.73? /needinfo

Here it's still happening, although less frequently.

/bugreport

Hi there!

We need a bit more information to really debug this issue. Can you add a "Report Bug" zip file here? You right click on our system tray icon and just go to report bug. Then drag the zipfile from your desktop onto the GitHub comment box in this issue. Thanks!