以下の実装が噛み合っていないものと推測しています。

• channels/followed.tsに渡されるsinceId/untilIdの種別
  →ここで渡ってくるのはchannel.id
• channel_following向けのクエリビルダ
• QueryService.makePaginationQueryの実装
  →sinceId/untilIdで絞り込む対象のカラムはid固定

上記から、channel_following.idに対しsinceId/untilIdを使って絞り込みを測るも、channel.idとchannel_following.idは別物であるため意図せぬ動作をしているものと考えました。
なので、絞り込み対象のカラムをchannel.idと同種であるchannel_following.followeeIdにすれば期待する動作となるかと思います。

以下のようにすればいけるかなと思ったのですが、如何でしょうか。
方針的によさそうであれば、プルリクを作ろうかと思います。

// 絞り込み対象とするカラムを外から設定できるようにする
// （他箇所に影響がないように元々固定で設定されていたidカラムをデフォルト値とする）
public makePaginationQuery<T extends ObjectLiteral>(
	q: SelectQueryBuilder<T>,
	sinceId?: string | null,
	untilId?: string | null,
	sinceDate?: number | null,
	untilDate?: number | null,
	columnName = 'id',
): SelectQueryBuilder<T> {
	if (sinceId && untilId) {
		q.andWhere(`${q.alias}.${columnName} > :sinceId`, { sinceId: sinceId });
		q.andWhere(`${q.alias}.${columnName} < :untilId`, { untilId: untilId });
		q.orderBy(`${q.alias}.${columnName}`, 'DESC');
	} else if (sinceId) {
	        q.andWhere(`${q.alias}.${columnName} > :sinceId`, { sinceId: sinceId });
        	q.orderBy(`${q.alias}.${columnName}`, 'ASC');
        } else if (untilId) {
	        q.andWhere(`${q.alias}.${columnName} < :untilId`, { untilId: untilId });
	        q.orderBy(`${q.alias}.${columnName}`, 'DESC');
        ....

// sinceId/untilIdと同種のfolloweeIdで絞り込めるようにカラム名を渡す
const query = this.queryService.makePaginationQuery(this.channelFollowingsRepository.createQueryBuilder(), ps.sinceId, ps.untilId, null, null, 'followeeId')
    .andWhere({ followerId: me.id });

channels/followed でチャンネルではなく ChannelFollowing を返さないとダメそう

ChannelFollowing を返さないとダメそう

となると…channelEntityService.pack()の流用はできなくなるので、channels/followed専用のものを新たに作成してそれを使うようにするイメージでしょうか（idはchannel_following.idを返すようにして、別にchannelIdみたいなパラメータを増やして返す）

上記方針だとフロント側やサードパーティアプリの該当機能も修正する必要が出てきますね…

@syuilo
互換性の観点から今のchannelIdを返す形を崩したくないのですが、どうでしょうか…

v2として新設するとか

v2として新設するとか

これはバグの認識なので、仕様（channelのidを返す）を維持したまま期待動作になるよう修正するのがベストだと考えます。
平行線だと良くないので、以下の2点についてお伺いします。

• 現行のchannel.idを軸としたリストを返却することに対して懸念はありますか？
• ChannelFollowing を返さないとダメそうという理由もご教示願いたいです

現行のchannel.idを軸としたリストを返却することに対して懸念はありますか？

ChannelFollowing を返さないとダメそうという理由もご教示願いたいです

ChannelFollowingを取得するAPIでChannelが返ってきてしまっているからいつフォローしたかとかの情報が取れない

ChannelFollowingを取得するAPIでChannelが返ってきてしまっているからいつフォローしたかとかの情報が取れない

現状持ってないです…

IDは日時情報入ってるわね

ChannelFollowingに限らずMisskeyにおける全てのIDは日時情報がミリ秒単位で入っていてレスポンスのcreatedAtとかはそこから持ってきてる

いつフォローしたかとかの情報をどう賄うかは理解しました。
しかし、現状は「いつフォローしたか」の情報を使用していないので、互換性を切ってまでChannelFollowingのIDを返す理由が思い当たらず…

v2で新設すれば全てが解決すると思ったけど懸念あるかしら

v2で新設というのは、ChannelFollowingのIDをベースにしたものを新しく作るという事ですか？
となると、現行のバグはそのままということでしょうか…（これが懸念）

そうね
バグを解決するには現状のレスポンスだと不可能と思うからバグを解決したエンドポイント新設して現行のはそのままにするしかない気がする

なるほど。v2を推される理由は理解しました。

現状のレスポンスだと不可能

#12175 (comment)
それこそ上記コメントの実装か、上記が適わない場合はchannelIdを使用したsinceId/untilIdによる絞り込みクエリを追加する処理をフォロー中チャンネル一覧APIに追加すれば直せそうですが…

ほむん

実装できるならそれで良さそう