Calling peripheral.wrap on an inventory and calling the list method in a coroutine seems to have an odd behaviour

[Shiranuit]

I'm not sure if this is a bug or I'm not understanding how this works

If you are placing a chest next to a computer and wrap it as a peripheral.
Then you try to call the list method of the inventory peripheral inside a coroutine, which yields the coroutine.
The first call to coroutine.resume then return true, "task_complete" which means a task_complete event has been emitted and contains the result of the call to list.

There are multiple thing that seems odd:

• When the call to list() occurs it yield with task_complete but does not give a task_id which means if there are multiple task_complete event we cannot know which result belong to our coroutine
• Resuming the coroutine after that doesn't do anything, even though there is still code that needs to be executed after the first yield
• The coroutine is marked as suspended and doesn't seems to end at any point in time after

I tried to find what could be causing this in the source code but wasn't able to find if this was intended or not, I didn't have much time to look deeply into it.

local p = peripheral.wrap("right") -- chest

local co = coroutine.create(function()
    print("before") -- Print "before"
    local list = p.list() -- Yields the coroutine
    print("after") -- Unfortunately does not come here event after resuming the coroutine another time
    for k, v in pairs(list) do
        print(k, v)
    end
end)

print(coroutine.resume(co)) -- success, task_complete
local event, task_id, success, list = os.pullEvent("task_complete")
print(coroutine.status(co)) -- suspended
coroutine.resume(co, list)  -- resumes the coroutine with the obtained list of items, but nothing happens

[SquidDev]

TLDR: Peripheral functions should be treated as a black box, like any like other user provided function. The events they pull, and what those events contain, isn't part of the public API, and so isn't guaranteed to be stable.

When the call to list() occurs it yield with task_complete but does not give a task_id which means if there are multiple task_complete event we cannot know which result belong to our coroutine

When a function/program/coroutine pulls an event, it doesn't contain anything aside from the event name (in the same way that http.get just pulls the http_* events, rather than http_* and a URL).

Resuming the coroutine after that doesn't do anything, even though there is still code that needs to be executed after the first yield

The coroutine is marked as suspended and doesn't seems to end at any point in time after

In your example code, you resume the coroutine with just the list parameter. What you actually want to be doing is resuming with all event arguments, so something like:

local event = table.pack(os.pullEvent("task_complete"))
print(coroutine.status(co)) -- suspended
coroutine.resume(co, table.unpack(event, 1, event.n))

That said, there's no guarantee that this task_complete event is the right one (or even if the function requested a task_complete event!), so you really should run a "full" event dispatch loop, which looks something like:

local ok, filter = coroutine.resume(co)
while coroutine.status(co) ~- "dead" do
  local event = table.pack(os.pullEvent(filter))
  ok, filter = coroutine.resume(co, table.unpack(event, 1, event.n))
end
if not ok then error(filter, 0) end

[Shiranuit]

I see, thanks you for your explanation, I didn't think the peripheral would be waiting until we give him exactly all the values from the task_complete event but more like the call was yielding the coroutine just waiting for a call to resume not waiting for any value in particular.
This explains the odd behaviour of the coroutine not ending, because the call was waiting for specific values to be resumed with, which is why the parallelAPI is designed like what you gave in the example, didn't think this was an important part.

Either way, thank you.