Almost-reliable confusing SymLink behaviour

I'm finding that intermittently, calling $modx->resource->get('id') on a SymLink is returning the ID of the target instead of the SymLink. This function is being called in a Snippet which is being called uncached as the very first item in a template.

In system settings I have symlink_merge_fields set to 'Yes' and 'id' isn't in the list of forward_merge_excludes so from what I can tell, the SymLink ID should be 'overwriting' the target ID 100% of the time based on updates made in the 2.0.5(?) update.

The only pattern I can see is that it happens regularly after I've made changes to settings or the target page, but it doesn't happen every time (argh!)

Then, if I clear the cache or edit the SymLink or the target again (which both clear the cache on save), then everything reliably goes back as expected with the SymLink returning its own ID instead of the targets.

I'm running MODX 2.2.8-pl on MODX Cloud.

I hate coming to the community with items that are this vague because I don't know how anyone might solve them with such vague parameters (not being reliably reproducible), but if anyone has any suggestions for paths of further investigation, that would be much appreciated!

Hm... after several changes to both System Settings and the target page (#3) it still always returns 16 (the ID of the symlink resource). Any idea what kind of changes?

Yeah - no pattern as far as I can possibly tell. Happens (unreliably but intermittently) with 'core' fields and multiple types of TVs and I've also seen it after changes to the merge system settings listed above. Might be time to try disabling all my extras (had already disabled all the plugins in testing)...

Are these SymLinks within a single Context, or are they referencing Resources across Contexts?

All within one context in a site with only the default 'web' context.

I just resolved an issue regarding the behavior of cached cross-Context SymLinks for 2.2.9, but I could not reproduce these issues with SymLinks within a single Context. Can you please open an issue in the bug tracker for this so we can track and collect more details on this almost-reliable problem several of you are experiencing?

I can do, but would it be worthwhile proving it's an actual bug first? It looks buggy, but how much use is it to create a report when there's so little to report? Does it become useful as a gathering area for similar reports?

I think I may have bug #7573 on my hands. Mine hasn't been as 'reliable' but the pattern described is one level of complexity higher than I was thinking so it may be a match.

Will test further and confirm if it seems to match that behaviour.

Yep - what I have is a duplicate of issue #7573. It just plays out for me as the wrong ID being handed to the resource. I've duly updated that issue with more details in the tracker: http://bugs.modx.com/issues/7573.

Thanks for your push towards the tracker opengeek - I'll be sure to add that to my trouble shooting processes from now on!

Ah, so this is an issue with some components that are summarizing data from SymLinks. Thank you very much for the additional information.