Currently !cubeinfo (with no provided cube number) will return the most recent cube's data. However, this can be confusing if you issue !cubeinfo in a thread where an onder cube was sent (especially so on the public cube channel). You probably expect to get the info for that cube (especially for automatic cubes).
Since we only track the most recent cube (and, really, we don't want to keep around an unbounded number of cube number to thread mappings), we may need to modify the behavior to be closer to how !cuberocks and !cubesucks work. That is, allow it only in the channel/thread of the most recent cube. (There is already some code to fail if we issue a !cubeinfo and it might return data for a cube that was sent to a private channel to avoid leaking that information).
Qualified (that is, with a provided cube number) !cubeinfo can remain unaffected, of course, as it doesn't rely in automatically determining the cube to describe.
Currently !cubeinfo (with no provided cube number) will return the most recent cube's data. However, this can be confusing if you issue
!cubeinfoin a thread where an onder cube was sent (especially so on the public cube channel). You probably expect to get the info for that cube (especially for automatic cubes).Since we only track the most recent cube (and, really, we don't want to keep around an unbounded number of cube number to thread mappings), we may need to modify the behavior to be closer to how !cuberocks and !cubesucks work. That is, allow it only in the channel/thread of the most recent cube. (There is already some code to fail if we issue a !cubeinfo and it might return data for a cube that was sent to a private channel to avoid leaking that information).
Qualified (that is, with a provided cube number)
!cubeinfocan remain unaffected, of course, as it doesn't rely in automatically determining the cube to describe.