Issues with the latest updates?

Hello Everyone,

I had to do maintenance yesterday on a FreePBX17, I ran fwconsole ma upgradeall and then ran apt update, good I paid attention, and avoided the trixie install, not sure why the latest sysadmin wasn’t pushed to the stable repo, which would have avoided this.

Anyway, after this update, 100% of the extensions got FollowMe enabled. In addition to that, prior to this update, queue calls to extensions used to call the macro-dialout-one-predial-hook hook, but this changed to macro-dial-ringall-predial-hook. Obviously breaking integrations…

Finally, logging to the full log has stopped, I had to go to the GUI and change it from On to 3.

Did anyone else notice this? Was there any announcements about the last three points that I missed?

Thanks

Hopefully not another instance of poor QA

Please provide mirror information and module version list. pastebin.freepbx.org is fine.

root@ADH-SP-PBX1:~# fwconsole setting --list | grep -i mirr
| PM2PROXY                                   | http://mirror.freepbx.org:6767/           

Modules: Automatic Pastebin from Sangoma OS 7 - FreePBX Pastebin

What about:

fwconsole setting MODULE_REPO

?

Regarding outside integrations with unknown parts, well, not every change combination is covered by standard internal QA.

Per logging change, that was probably covered a couple of weeks ago.

root@ADH-SP-PBX1:~# fwconsole setting MODULE_REPO
Setting of "MODULE_REPO" is (text)[https://mirror.freepbx.org]

Changing the predial hooks a queue uses is a pretty big change IMO.

There are the built-in hooks that people rely on, if an update simply stops any of these hooks from becoming relevant, then what is the point of allowing these hooks?

I am not mad, but I want you to understand how this customer looks at us.

They had a minor issue which required a PBX reboot, if we are already rebooting, then why not do maintenance?
We did.

Which resulted in:

  • ARI Broken, since it was changed from 0.0.0.0 to 127.0.0.1
  • FollowMe enabled on all extensions
  • Several custom features stopped working since the hook is looking hooking.
  • We weren’t able to right away diagnose these issues, since logging wasn’t working.

We got an email the following day that said something along the lines:

You started using AI? In the 7 years we have been with you guys we never had so many broken things and issues in one day. What happened?

1 Like

Changing how the hooks work, are called or are named isn’t just something you can do without warning the user base that a major change like this is going to happen and could break integrations.

No one is asking Sangoma to test various custom integrations, we’re asking that making changes to how those integrations work should be announced a head of time.

2 Likes

This is going to keep biting people. Absolutely crazy and not like we didn’t say something before it went to stable. What’s the point of giving feedback here?

Anyone know the cause of this?

When is this going to be fixed @penguinpbx ? People have been complaining about it for months.

1 Like

Thank you for your previous suggestion from several weeks ago for those users that require looser ARI binding.

Logging was addressed previously in this current topic.

It was addressed that someone else also reported this on the forums. Would you know if an issue was filed and it was fixed?

Meaning anyone who uses ARI or webrtc needs to experience breakage and then come to the forums and search for the solution?

I do not think this is a good user experience.

1 Like

Hmm, how about this instead:

anyone who uses ARI or webrtc needs to experience the joy of testing thoroughly in staging before updating production

:thinking:

Maybe some aggregated Changelog “top 10” this week/month would be helpful ?

Here’s the changelog related to the https binding:

If I’m a thoughtful admin and read the change logs before updating modules that’s all I’ve got to work with, a single line saying “Adjusted for Local Access Only.” There’s no sense given here that this will break ARI or webrtc.

Other open source projects loudly proclaim breaking changes, often accompanied by a major version increment. This was a major change hiding after three decimal points in the version number. It’s possible that the misunderstanding here is that we disagree on what is a major change, but I assert that anything that changes the network configuration without asking is certainly a major change.

So yeah a “changelog top 10” would be great, with notice that the changes are going into edge on date X, proposed to go to stable on date Y, and with time for feedback. In this case I understand it was a security release, but the breaking change should still be noted even if it’s being rushed to stable.

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.