`public_key' mayhem (or something worse?)

Ok. So, my progress report has an entry that has a term that is killing my VM, and then, my server. It’s the cacerts key-val that is doing it and since I am logging progress, errors, etc., it does all this IO and starves my server. So, no errors this time, but this supervisor combined with SASL is the culprit:

=PROGRESS REPORT==== 6-Jan-2024::15:02:11.513897 ===
    supervisor: {<0.1021.0>,tls_dyn_connection_sup}
    started: [{pid,<0.1023.0>},
              {id,receiver},
              {mfargs,
               {ssl_gen_statem,start_link,
                [client,<0.1022.0>,"www.reddit.com",443,#Port<0.14>,
                 {#{alpn_advertised_protocols => undefined,
                    customize_hostname_check =>
                     [{match_fun,#Fun<public_key.6.11965134>}],
                    signature_algs_cert => undefined,
                    partial_chain => #Fun<ssl.5.74402199>,protocol => tls,
                    crl_cache => {ssl_crl_cache,{internal,[]}},
                    key_update_at => 388736063997,verify_fun => undefined,
                    signature_algs =>
                     [{sha512,ecdsa},
                      rsa_pss_pss_sha512,rsa_pss_rsae_sha512,
                      {sha512,rsa},
                      {sha384,ecdsa},
                      rsa_pss_pss_sha384,rsa_pss_rsae_sha384,
                      {sha384,rsa},
                      {sha256,ecdsa},
                      rsa_pss_pss_sha256,rsa_pss_rsae_sha256,
                      {sha256,rsa}],
                    early_data => undefined,log_level => notice,
                    max_fragment_length => undefined,
                    versions => [{3,3}],
                    secure_renegotiate => true,verify => verify_peer,
                    cacerts => ...

The final key of cacerts points to the endless barrage of terms. That value is the whopper.

If anyone can best advise how to `shush’ certain progress reports, that would be amazing – unlikely. I don’t think I want to disable these, so a best practice here would be great!!

EDIT: This is a legacy project, so the issue seemed to be NOT the fact that such a large term was being written to logfile, but rather, since these gigantic progress reports were IO to tty.

Sadly, these humongous terms in the logfile coming from the progress reports are still corrupting my SASL logfiles. If I find a solution to that, I’ll be happy. But I fixed the thread’s main issue by ensuring {errlog_type, error} was set to stop tty getting pounded (shouldn’t this also prevent logfiles from getting progress reports? I thought it should, and nothing in the man says otherwise… ).