Agents can be archived

[knu]

Some of the existing Agent types have already stopped working and need to be either deleted or updated, but currently, Huginn is very awkward at obsoleting an Agent type. If a Huginn database had any existing instance of the type, deleting the Agent implementation could render the entire Huginn server dysfunctional because Huginn uses STI where retrieving an Agent record with a non-existent type will immediately cause an error.

This PR provides a way to "archive" agents by converting them to a new Agent type called "ArchivedAgent" with all states and configuration options saved. Once an agent is archived, it is disabled and becomes dormant. The archiving is intended to take place in database migrations so deleting an Agent type wouldn't cause trouble to users.

Archived agents could be unarchived someday when a successor Agent type got ready.

[virtadpt]

Would this problem prevent it from archiving those agent classes?

[knu]

@virtadpt I'm afraid not. I guess the schema_migrations table got hosed and the db:migrate tried to run migrations that had already been run. What does select * from schema_migrations show? If it's empty for some reason, and you are sure the Huginn was at least the latest version after 2017-07-31, then you could insert all existing migration versions found in db/migrate.

[knu]

This is set to the draft state only because the branch is based on ruby-3.2. Once #3216 gets merged I'll rebase this on the default branch.

[virtadpt]

select * from schema_migrations is showing an empty table. 0) Oh, shit, and 1) good call.

I know the version I've been running was after 2017-07-31 because I keep written (well, copy and pasted) records for debugging purposes.

I guess I need to figure out how to populate that table.

Edit: Done. And ticket closed.

[dsander]

I like the idea of making our current approach of forcing the user to delete their Agent instances of deleted agent types more user friendly!

If a Huginn database had any existing instance of the type, deleting the Agent implementation could render the entire Huginn server dysfunctional because Huginn uses STI where retrieving an Agent record with a non-existent type will immediately cause an error.

We do already have this, how would one get to a state you are describing?

It looks to me that with the ArchivedAgent approach users would need to manually modify the database state after somehow a successor of the previous Agent was added to their instance. I wonder if we could somehow automatically cast deleted into an "degraded" state while still preserving the original database records.

For this scenario I am thinking about either us removing an Agent (or an agent gem not being enabled for some time) which is then later replace by another agent gem. If the new Agent would have the same class name and supported the same options, everything would start working againi without any interevention.