Retry flows fails with "Data too long for column 'results' at row 1"

[Ann Taraday]

When we need to have a big number of retries, execution of tasks starts to fail with http://paste.openstack.org/show/754891/
The root cause of it that each time history save a lot of information about failures, example of such data http://paste.openstack.org/show/754892/.
Taskflow should provide a way of refreshing retries history or a separate history class which will contain reduced among of information.

[Michael Johnson (johnsom)]

It seems like the "results" field in the database grows with each retry iteration, which if we have a large number of retry iterations (waiting for a vm to boot on slow nested virt hosts for example) this column becomes very large.
I'm wondering if taskflow could use a refactor for this.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/675388
Committed: https://git.openstack.org/cgit/openstack/taskflow/commit/?id=f0eae2cc7c1222ee1bbc1a0018337fb2a2289de2
Submitter: Zuul
Branch: master

commit f0eae2cc7c1222ee1bbc1a0018337fb2a2289de2
Author: Ann Taraday <email address hidden>
Date: Thu Aug 8 16:56:04 2019 +0400

    Use mysql LONGTEXT for atomdetails results

    With a lot of possible retries using mysql sa.Text for result field
    atomdetails table is not enough.

    Updated 'results' column type to LONGTEXT in mysql backend case.

    PosgreSQL seems not to be affected as postgres text type is not
    having length limitation.

    Co-Authored-By: Michael Johnson <email address hidden>

    Change-Id: I4e44e3288ae49d85c5b5ce8ff26ba83f3b9d2c7b
    Closes-bug: #1838015

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/taskflow 3.7.1 release.