PSA: LM wipes good known properties when unknown results occur

Ah, that’s from Device_BasicInfo, which really has too many properties for one module. They could put try/catch blocks in there, but if one single try fails, the whole thing would have to be ignored. Meaning that if one property failed to get fetched, updates for the other properties wouldn’t get processed. They really should break that PS up into multiple modules each with its own try/catch block. That way if one property fails, the blast radius is reduced.

Yeah, I never clone. It’s a bad option.

For PropertySources and AD scripts (and i think ConfigSources), if the script returns a non-zero value, LM is supposed to ignore the task output altogether. So that should be codable using try blocks. Are you saying there are modules where failure can happen and it still returns a 0 without all the previously known properties? Which module(s)?

We don’t have access to the code that does system discovery though so system.ips getting changed when a discovery task fails is worrysome.

Yeah, I also generally refuse to use the clone/edit method they espouse due to the obvious maintenance nightmare.  I recognized that almost immediately after starting to use the product many years ago and pushed for inheritance for a long time before giving up.  My code is outside LM, related to downloading configsource versions to email diffs via git commit hooks (since LM unbelievably lacks support for that natively). I have had to add numerous extra checks to avoid committing garbage to our repos. The garbage still exists in the LM change history, but not in our repos -- I do get error reports from the script frequently when garbage is detected and skipped.

For modules, yes, the cases I have seen are for things like AD configsource modules where lack of exception handling leads to fully or partially empty data that replaces previous results.  I’ve also often seen similar issues with network devices where you see errors, “false”, etc. replace the entire previous config. The newer modules are better but still suffer from this problem sometimes (see all the extra code I’ve had to add to avoid thrashing in my local repos in the lm-get-configs script in my github repo).

I never did get a good answer on why an access blip causes buitin properties like system.ips to thrash, nor did they take it seriously enough to escalate to the developers.

Lack of exception handling should at least be in their jira backlog to fix. If it’s not, that’s really concerning.

Not fully understanding your setup, but if you’re like me you want to avoid forking modules away from the repo version. I assume your deviations are what are in your github repo?

I do wish they’d make the system discovery code accessible so we can help them debug it. They’ve been bleeding really good talent starting a year ago and the quality of code has suffered for it.

Related to the property thrashing, we see the same all the time for auto properties.  Admittedly, it could be tricky to code for, but setting a timer for valid lifetime of those could be one solution rather than deleting them because the corresponding modules failed to get data.  This is a sample of what I see happen all the time.