API inconsistency of the GET /source/{prj_name} route with deleted=0 parameter showing multibuild packages

[dcermak]

Issue Description

The GET /source/{prj_name} is inconsistent when it comes to the deleted=0 parameter. Omitting the parameter lists only source packages but adding it includes multibuild flavors

Expected Result

The output of GET /source/{prj_name} and GET /source/{prj_name}?deleted=0 should be the same.

How to Reproduce

$ osc api '/source/devel:microos'|grep ":"|wc -l
0

$ osc api '/source/devel:microos?deleted=0'|grep ":"|wc -l
2

Additional Info

This appears to impact interconnect in some way as well:

$ osc api '/source/devel:BCI:SLE-15-SP6'|grep ":"|wc -l
0

while there are multibuild flavors via interconnect on IBS:

$ isc api '/source/openSUSE.org:devel:BCI:SLE-15-SP6'|grep ":"|wc -l
2

[hennevogel]

Does this have some impact for something you do?

[dcermak]

Does this have some impact for something you do?

yes, especially the last one is annoying as I get different results over interconnect

[eduardoj]

Related to already closed #9715.

[adrianschroeter]

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.

[adrianschroeter]

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.

[dcermak]

delete=0 is currently used as workaround to get the backend answer, so we can not do this.

Wouldn't it make more sense to use a private API for this?

Please just don't send the delete query parameter if you don't want the multibuild containers.

I am not doing this, but something in the interconnect code does that for me.

Also, osc ls sends deleted=0 by default (jfyi @dmach), that's how I found this

[eduardoj]

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.

The documentation states for the deleted parameter: Set to 1 to list the packages of a deleted project.

It is not explicitly defined what happens if passing an empty deleted parameter, or deleted=0... Nothing I would change from the documentation part.

But I would expect some consistency on the result of the endpoint in all the cases where we don't pass deleted=1.

[danidoni]

Adrian,

delete=0 is currently used as workaround to get the backend answer, so we can not do this.

Where is this being used? Can you point me to it?

[hennevogel]

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>

[dcermak]

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

[hennevogel]

No, scmsync is involved here,

I was talking about where this is used...

[adrianschroeter]

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.

[dcermak]

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?

[adrianschroeter]

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.

[adrianschroeter]

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 ....