[ZendTo] Problem updating 6.05-4 to 6.13-3

[John Thurston]

I can see what you mean when I look at my new-to-me 6.13 
test-installation. Thank you for the guidance.

On that system, after I make a 'request', the "Global Drop-off List" has 
similar looking numeric "Claim ID" (e.g. "828 320 622") and the word 
"Request" in the "Size" column. Interestingly, the 'requests' are shown 
with yellow backgrounds in the table cells.

On the system I updated from 6.05 --> 6.13, the numeric entries appeared 
with "0" (zero) in the "Size" column (rather than the word "Request"). 
And they appeared in the same table color-scheme as all of the drop-offs.

On that system, the entries carried dates ranging from 20240416 --> 
20241112 (our requests should expire after 7 days). They all appeared 
with numeric "Claim ID", "0" in the "Size", and with no distinctive 
background. So my concerns here are:

  * Some parts of the code recognize them as Requests, other parts seem
    not to
  * New Requests must be stored differently than old instances, as they
    are displayed differently in the Global List

 1. Will these Old Requests (which display differently), behave as expected?
 2. Will the ancient Requests now be caught by the reaper?

I can live with yes or no for either question. I'd like to know what to 
tell my customers to expect.

--
Do things because you should, not just because you can.

John Thurston    907-465-8591
John.Thurston at alaska.gov
Department of Administration
State of Alaska

On 11/13/2024 6:51 AM, jules at zend.to wrote:
> The ones with the numeric values should be labelled as "requests" in 
> one of the other columns. They are requests-for-dropoffs, not dropoffs 
> themselves. They should get cleared up like they have been in the 
> past, it's just now they show in that table.
>
> Cheers,
> Jules.
>
>
> On 13/11/2024 3:25 pm, John Thurston via ZendTo wrote:
>>
>> Updating our test-system seemed to work perfectly. Not so for production.
>>
>> After updating from 6.05-4 to 6.13-3, I have some strange behavior 
>> (and have reverted to the old, by way of a VMWare snapshot).
>>
>> New drop-off and pickup seems to work as expected. Picking up recent 
>> drop-offs seemed to work as expected. But the "Show All Drop-offs" 
>> now contains some entries with numeric values (e.g. "235 637 597") in 
>> place of the expected strings (e.g. "22iUmVdjs9WxszxD"). I exported 
>> all of the drop-offs to a CVS. All of the numeric clamIDs show a zero 
>> size. And most of them are well past their expiration date. Most are 
>> only a little old, but some are more than 6-months old.
>>
>> So I /suspect/ there are some old entries in the database which 
>> weren't cleaned up in the normal course of operations. The new code 
>> in 6.13 is finding them, interpreting them, and adding them to the 
>> list of available downloads. I also /suspect/ that the next reaping 
>> through the database by the new code would clean them out.
>>
>> But I couldn't be sure, so I've reverted to 6.05 while I try to 
>> figure out what it is doing and if it is safe.
>>
>> I know that 6.13 is now a couple of years old, so others probably 
>> performed their update in the distant past. But does anyone have any 
>> insight or advice?
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jul.es/pipermail/zendto/attachments/20241113/07511b27/attachment-0001.html>