Bug 1131954 - Behavior around 'updated_at' changed for :repositories :show
Summary: Behavior around 'updated_at' changed for :repositories :show
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: API
Version: Unspecified
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: Unspecified
Assignee: Bryan Kearney
QA Contact: Katello QA List
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-08-20 11:41 UTC by Matej Kollar
Modified: 2019-09-26 13:49 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-01-13 19:55:01 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
reproducer (1.93 KB, application/x-ruby)
2014-08-20 11:41 UTC, Matej Kollar
no flags Details

Description Matej Kollar 2014-08-20 11:41:41 UTC
Created attachment 928769 [details]
reproducer

Description of problem:
When I run sync for the newly created repository, after sync is finished, I expect

    res = api_call(:repositories, :show, {'id' => repo['id']})
    Time.parse(res['last_sync']) >= Time.parse(res['updated_at'])

to be true, that means time of last sync to be after last modification.

How reproducible: always/deterministic


Steps to Reproduce:
  1. run attached reproducer

Actual results: result is false

Expected results: result is true

Additional info:
This is regression. Described behaviour was first observed/noticed with compose Satellite-6.0.4-RHEL-6-20140813.2-Satellite-x86_64.


Also, when I start sync, wait for it to finish, start sync again and again wait for it to finish, (it is commented out in reproducer after first sync), then it returns (as I would expect) true.

Comment 4 Bryan Kearney 2016-07-08 20:27:17 UTC
Per 6.3 planning, moving out non acked bugs to the backlog

Comment 6 Amit Karsale 2016-07-29 06:39:50 UTC
the response structure for individual repository API(katello/api/repositories/:id) has been changed now in satellite 6.1+ as compared to previous response(when the BZ was created). Currently the `last_sync` attribute is a hash object with inner attributes as follows:

"last_sync": {
  		"id": "3181854a-a97b-43dc-aa0b-461d50fe0da5",
  		"username": "admin",
  		"started_at": "2016-04-20 13:05:43 +0530",
  		"ended_at": "2016-04-20 13:47:31 +0530",
  		"state": "stopped",
  		"result": "success",
  		"progress": 1.0
  	}

Also the `started_at` and `ended_at` timestamp is greater than `updated_at` attribute. I guess there is nothing to do on this BZ now.
This bugzilla can be closed.


Note You need to log in before you can comment on or make changes to this bug.