oldest_first=True in the audit logs returns newest_first

[champymarty]

Summary

When trying to get oldest_first, it returns newest firsts

Reproduction Steps

I am trying to get the oldest_first in the audit logs:

                async for entry in guild.audit_logs(limit=None, after=object_id,
                                                    oldest_first=True, action=discord.AuditLogAction.member_role_update):
                    print(f'{entry.created_at}')

But it is returning the most recent first ...

2023-12-28 19:49:21.731000+00:00
2023-12-28 19:49:18.526000+00:00
2023-12-28 19:49:14.620000+00:00
2023-12-28 19:49:11.040000+00:00

Minimal Reproducible Code

async for entry in guild.audit_logs(limit=None, after=object_id,
                                                    oldest_first=True, action=discord.AuditLogAction.member_role_update):
                    print(f'{entry.created_at}')

Expected Results

2023-12-28 19:49:11.040000+00:00
2023-12-28 19:49:14.620000+00:00
2023-12-28 19:49:18.526000+00:00
2023-12-28 19:49:21.731000+00:00

Actual Results

2023-12-28 19:49:21.731000+00:00
2023-12-28 19:49:18.526000+00:00
2023-12-28 19:49:14.620000+00:00
2023-12-28 19:49:11.040000+00:00

Intents

moderation, members, guilds

System Information

• Python v3.11.1-final
• py-cord-dev v2.5.None-candidate
  • py-cord-dev pkg_resources: v2.5.0rc5
• aiohttp v3.8.5
• system info: Windows 10 10.0.22631

Checklist

• I have searched the open issues for duplicates.
• I have shown the entire traceback, if possible.
• I have removed my token from display, if visible.

Additional Context

No response

[champymarty]

In the mean time I just did:

entries = await guild.audit_logs(limit=None, after=object_id,
                                    oldest_first=True, action=discord.AuditLogAction.member_role_update).flatten()
entries.sort(key=lambda val: val.created_at)

[NeloBlivion]

Might be a breaking change because oldest_first doesn't exist on the API, will follow spec instead

[Lulalaby]

Approved, do it

[champymarty]

There is also a problem where the audit_log will fetch so much more logs than required. This is cause when there is more than 100 logs to fetch, the iterator does not execute the logs in the right orders. It can only appear when more than 100 logs, becuase the iterator fetch logs in batch of max 100. For exemple there is 134 logs to fetch but it will fetch 3600 logs... That can be a big problem for performance and rate limits.

I put more details when I prosented the problem in the help server: https://discord.com/channels/881207955029110855/1132206148309749830/1208967662663897108