API inconsistency of the GET /source/{prj_name} route with deleted=0 parameter showing multibuild packages #16911
Comments
|
Does this have some impact for something you do? |
yes, especially the last one is annoying as I get different results over interconnect |
|
Related to already closed #9715. |
This way `?delete=0` and `?` behaves consistently, and only `?delete=1` activates the behaviour for deleted projects Fixes openSUSE#16911
|
delete=0 is currently used as workaround to get the backend answer, so we can not do this. Please just don't send the delete query parameter if you don't want the multibuild containers. |
This way `?deleted=0` and `?` behaves consistently, and only `?deleted=1` activates the behaviour for deleted projects Fixes openSUSE#16911
|
and use just ?deleted if you want it. This is the meanwhile documented way, there is actually no reason to add a value to it. However, since some tools need to by-pass the api, because they require the backend informations (eg. for originpackage information), we can not become incompatible here. |
Wouldn't it make more sense to use a private API for this?
I am not doing this, but something in the interconnect code does that for me. Also, |
There was a consistency gap between sources coming from local projects and sources coming from remote projects. Multibuild flavors were only shown for remote projects. Now the multibuild flavors are shown in both cases. Fixes openSUSE#16911
There was a consistency gap between sources coming from local projects and sources coming from remote projects. Multibuild flavors were only shown for remote projects. Now the multibuild flavors are shown in both cases. Fixes openSUSE#16911
The documentation states for the It is not explicitly defined what happens if passing an empty But I would expect some consistency on the result of the endpoint in all the cases where we don't pass |
|
Adrian,
Where is this being used? Can you point me to it? |
|
Guess another |
|
Henne Vogelsang ***@***.***> writes:
Guess another `scmsync` thing?
```
➜ ~ osc -A https://api-test.opensuse.org api '/source/home:hennevogel:scmsync-project'
<directory count="0"/>
➜ ~ osc -A https://api-test.opensuse.org api '/source/home:hennevogel:scmsync-project?deleted=0'
<directory>
<entry name="ctris"/>
<entry name="ponysay"/>
<entry name="webhook"/>
</directory>
```
No, scmsync is involved here, but you can observe the multibuild
behavior also for ordinary projects without scmsync
|
I was talking about where this is used... |
|
again, deleted=0 is unfortunately an expected workaround of many tools (including osc) to bypass the api answer. There are many reasons to do so, as the api answer is incomplete in many situations. multibuild is one thing, project link is another one, scmsync yet another, remote projects one more and I may have forgotten more situations. And yes, you can even combine these. We accept this inconsistency, as for many usecases the simple api (aka database) answer is good enough. And there is no reason to break these implementation and cause plenty of problems in many client tools. However, if you are not aware of the differences of "deleted=0", just use the documented api way by using it either as boolean "?deleted&..." or don't use the deleted argument. So where is the problem at all? Having two different answers based on the cgi parameters is absolute okay IMHO. |
|
Adrian Schröter ***@***.***> writes:
again, deleted=0 is unfortunately an expected workaround of many tools (including osc) to bypass the api answer. There are many reasons to do so, as the api answer is incomplete in many situations. multibuild is one thing, project link is another one, scmsync yet another, remote projects one more and I may have forgotten more situations. And yes, you can even combine these.
We accept this inconsistency, as for many usecases the simple api (aka database) answer is good enough. And there is no reason to break this implementation and cause plenty of problems in many client tools.
However, if you are not aware of the differences of "deleted=0", just use the documented api way by using it either as boolean "?deleted&..." or don't use the deleted argument.
So where is the problem at all? Having two different answers based on the cgi parameters is absolute okay IMHO.
The problem is that I cannot make the interconnect code omit
`?deleted=0` (or make it behave similarly):
❯ osc api '/source/devel:BCI:SLE-15-SP6'|grep ":"
# = no results
but over interconnect I get:
❯ isc api '/source/openSUSE.org:devel:BCI:SLE-15-SP6'|grep ":"
<entry name="sac-apache-tomcat-10-image:openjdk17" originpackage="sac-apache-tomcat-10-image"/>
<entry name="sac-apache-tomcat-10-image:openjdk21" originpackage="sac-apache-tomcat-10-image"/>
which is the same reply that I obtain via:
❯ osc api '/source/devel:BCI:SLE-15-SP6?deleted=0'|grep ":"
<entry name="sac-apache-tomcat-10-image:openjdk17" originpackage="sac-apache-tomcat-10-image"/>
<entry name="sac-apache-tomcat-10-image:openjdk21" originpackage="sac-apache-tomcat-10-image"/>
So, how do I call the /source/{prj_name} route over interconnect and
make it omit the `deleted=0` parameter if it's not present in my query?
|
|
well, you can't atm, but couldn't you just ignore the additional information? Or you could always call with "deleted=0", so you would get a consistant behaviour, if this is more important. |
There was a consistency gap between sources coming from local projects and sources coming from remote projects. Multibuild flavors were only shown for remote projects. Now the multibuild flavors are shown in both cases. Fixes openSUSE#16911
There was a consistency gap between sources coming from local projects and sources coming from remote projects. Multibuild flavors were only shown for remote projects. Now the multibuild flavors are shown in both cases. Fixes openSUSE#16911
|
if consistency is really that important here, we may consider always deliver the backend answer for package listings and never generate it based on database data .... |
There was a consistency gap between sources coming from local projects and sources coming from remote projects. Multibuild flavors were only shown for remote projects. Now the multibuild flavors are shown in both cases. Fixes openSUSE#16911
Right now we use the presence of the `deleted` query parameter as a workaround in order to force the request being passed directly to the backend and returning results based on the backend data over returning results based on frontend database data. This workaround currently leads to inconsistant results being returned by the API. Instead of using this workaround we better should always let the backend handle the request and return the data based on it's info. Fixes openSUSE#16911
Right now we use the presence of the `?deleted=0` query parameter as a workaround to force the request being passed directly to the backend and returning results based on backend data over returning results based on frontend database entries. This workaround currently leads to inconsistant results being returned by the API. Instead of using this workaround we better should always let the backend handle the request (where possible) and return the data based on it's info. Fixes openSUSE#16911
Right now we use the presence of the `?deleted=0` query parameter as a workaround to force the request being passed directly to the backend and returning results based on backend data over returning results based on frontend database entries. This workaround currently leads to inconsistant results being returned by the API. Instead of using this workaround we better should always let the backend handle the request (where possible) and return the data based on it's info. Fixes openSUSE#16911
Right now we use the presence of the `?deleted=0` query parameter as a workaround to force the request being passed directly to the backend and returning results based on backend data over returning results based on frontend database entries. This workaround currently leads to inconsistant results being returned by the API. Instead of using this workaround we better should always let the backend handle the request (where possible) and return the data based on it's info. Fixes openSUSE#16911
We do this to be consistent with the behaviour showed when passing a remote project. Fixes openSUSE#16911
Issue Description
The
GET /source/{prj_name}is inconsistent when it comes to thedeleted=0parameter. Omitting the parameter lists only source packages but adding it includes multibuild flavorsExpected Result
The output of
GET /source/{prj_name}andGET /source/{prj_name}?deleted=0should be the same.How to Reproduce
Additional Info
This appears to impact interconnect in some way as well:
while there are multibuild flavors via interconnect on IBS:
The text was updated successfully, but these errors were encountered: