Tenho visto emojis quebrando em um site público que opero, o acl está definido como privado e marcado como seguro com a razão access control post dictates security | source: post creator.
Executar a tarefa uploads:secure_upload_analyse_and_update corrige o problema, mas ele ocorre novamente alguns dias depois. Isso também aconteceu com o logotipo do site uma vez, mas nunca mais ocorreu.
Olá @Wolftallemo, este é um problema complicado quando emojis personalizados (ou qualquer upload acessível publicamente que possa ser usado em uma postagem) e uploads seguros são combinados. Há um tempo começamos a usar uma tabela UploadReference para ver o que está vinculado a qual upload, no entanto, quando migramos para esta tabela, definimos todos os created_at datetimes para a mesma coisa. A consequência disso é que, quando verificamos se o primeiro uso de um upload é público ou não para fins de segurança, às vezes a ordem está incorreta e usamos a coisa errada, pois se ambas as coisas tiverem exatamente o mesmo created_at, o PostgreSQL faz o que quer:
Sua menção a isso me fez reexaminar isso mais uma vez, e acho que podemos lidar com isso melhor ordenando por created_at ASC depois id ASC, então, se houver algum desses conflitos, o registro real do primeiro uso deve ser usado.
Se os problemas persistirem após a fusão disso (tentarei fundi-lo hoje) e você tiver feito o upload do seu site, poderemos discutir mais opções, mas suspeito que este seja o problema para você. Você pode confirmá-lo fazendo isso e comparando os resultados em seu site:
CustomEmoji.find_by(name: "success").upload.upload_references.order("created_at ASC")
CustomEmoji.find_by(name: "success").upload.upload_references.order("created_at ASC, id ASC")
O primeiro deve ter um Post como target_type, o segundo deve ter o CustomEmoji como tipo de destino.
Começou a acontecer novamente, e parece ser o mesmo emoji toda vez.
Você pode executar as consultas que @martin compartilhou na postagem acima?
Olhando os resultados, estou obtendo o exato oposto (o primeiro retorna CustomEmoji e o segundo retorna Post)
Interessante, então está retornando a coisa certa. Para o upload vinculado, você pode postar os valores de security_last_changed_reason e security_last_changed_at e ver se access_control_post_id está preenchido? Não deveria estar marcando esse upload como seguro quando a primeira referência é o emoji personalizado. Tente isto também:
Upload.find(ID)
.upload_references
.joins(<<~SQL)
LEFT JOIN posts ON upload_references.target_type = 'Post' AND upload_references.target_id = posts.id
SQL
.where("posts.deleted_at IS NULL")
.order("upload_references.created_at ASC, upload_references.id ASC")
.first
E veja qual registro ele te dá.
Recebi controle de acesso postar dita segurança | fonte: criador da postagem com a data de qua, 22 de mar. de 2023 09:13:10.341411000 UTC +00:00
Ele me deu um ID de controle de postagem para uma postagem em uma categoria privada que foi criada há mais de três anos e nunca foi editada.
Interessante, e o emoji personalizado foi usado nesse post? O que é retornado quando você executa o código de referência de upload acima com esse ID de upload? Executar isso com o registro de upload e postar o resultado também seria útil:
UploadSecurity.new(upload).should_be_secure_with_reason
Foi usado nesse post
A consulta retornou o seguinte:
id: 752,
upload_id: 236,
target_type: "Post",
target_id: 37246,
created_at: Mon, 25 Nov 2019 22:24:50.002473000 UTC +00:00,
updated_at: Sun, 29 May 2022 08:13:24.844072000 UTC +00:00
>
O target_id aponta para um post que não contém o emoji.
A segurança do upload retorna [true, "o post de controle de acesso determina a segurança"]
Isso é realmente inesperado, executar isso deve fornecer todos os uploads vinculados à postagem via UploadReference:
UploadReference.where(
target_type: "Post",
target_id: 37246,
)
Se a postagem tiver referências, mas não parecer ter nenhum upload na interface do usuário, talvez tenha havido um problema de migração?
Acontece que digitei o id errado 
Sim, ele contém o emoji, embora o tópico pai tenha sido excluído.
Heh, sem problemas. Então, se você executar isso novamente com o upload correto, o que você obtém?
UploadSecurity.new(upload).should_be_secure_with_reason
E
upload
.upload_references
.joins(<<~SQL)
LEFT JOIN posts ON upload_references.target_type = 'Post' AND upload_references.target_id = posts.id
SQL
.where("posts.deleted_at IS NULL")
.order("upload_references.created_at ASC, upload_references.id ASC")
.first
Se realmente precisarmos, você pode simplesmente definir a data e hora de created_at do registro UploadReference de CustomEmoji para algo anterior a qualquer um dos outros registros UploadReference para esse upload, mas você não deveria ter que fazer isso.
Eu deveria ter esclarecido. O ID do upload estava correto, o ID da postagem não estava (que foi como acabei com a postagem não contendo o emoji - o que colei aqui estava correto, mas digitei errado ao tentar encontrá-lo)
Todos os outros comandos ainda retornam a mesma coisa
Se for este o caso, então realmente há alguma estranheza em torno das datas, possivelmente causada por nossa migração automática. Execute isto:
CustomEmoji.find_by(name: "success").upload.upload_references.order("created_at ASC, id ASC")
Para encontrar o registro UploadReference que diz target_type: "CustomEmoji", então faça:
UploadReference.find(ID).update!(created_at: UploadReference.find(752).created_at - 1.day))
Em seguida, execute isto no upload problemático:
upload.update_secure_status
E isso deve ser resolvido… Eu realmente acho que isso será principalmente um problema com uploads mais antigos desde esta migração. Outra coisa que você pode ser capaz de fazer é excluir o emoji personalizado, reenviá-lo e, em seguida, executar:
Jobs.enqueue(:rebake_custom_emoji_posts, name: EMOJI_NAME)
A atualização da data será mais fácil, no entanto. Desculpe pela confusão nisso!
Por enquanto o emoji não é mais seguro 
Acho que vou descobrir em alguns dias se realmente funcionou ou não
Olá @Wolftallemo 
Isso funcionou para você?
Nada quebrou ainda