Erro: WrongContainedType: ([ConstraintNotSatisfied(u'poll')], 'value') ao atualizar uma instalação 1.1.4 para 1.5.2
idgserpro opened this issue · comments
Durante a execução dos upgradeSteps de collective.cover, em:
Upgrade Step Group
-> Register calendar tile
Register calendar tile and make it available for inmediate use. (13 → 14)
-> Register calendar script
Register script to deal with tile's next/prev events. (13 → 14)
-> Cook CSS resources
There were changes in the CSS files, so we need to cook the resources. (13 → 14)
-> Cook JS resources
There were changes in the JS files, so we need to cook the resources. (13 → 14)
Recebemos o seguinte erro:
Traceback (innermost last):
Module ZPublisher.Publish, line 138, in publish
Module ZPublisher.mapply, line 77, in mapply
Module ZPublisher.Publish, line 48, in call_object
Module Products.GenericSetup.tool, line 1053, in manage_doUpgrades
Module Products.GenericSetup.upgrade, line 166, in doStep
Module collective.cover.upgrades.v14, line 21, in register_calendar_tile
Module plone.api.portal, line 2, in set_registry_record
Module plone.api.validation, line 70, in wrapped
Module plone.api.portal, line 367, in set_registry_record
Module plone.registry.registry, line 47, in __setitem__
Module plone.registry.record, line 82, in _set_value
Module zope.schema._bootstrapfields, line 182, in validate
Module zope.schema._field, line 478, in _validate
WrongContainedType: ([ConstraintNotSatisfied(u'poll')], 'value')
Não sabemos se é um alguma peculiaridade da instalação ou erro mesmo da solução IDG. Fato é que se você rodar 3x o upgradeStep, ele pára de dar o erro, portanto, a principal motivação da abertura desse relato é para ter a documentação desse paliativo caso mais pessoas atualizando o IDG nesse cenário também recebam esse erro.
acho que isso está relacionado a ordem que vocês rodaram os upgrade steps; confiram a ordem certa em: https://github.com/plonegovbr/portal.buildout/releases/tag/1.5.3
aliás, vocês tem que atualizar à última versão do branch 1.x.
O erro ocorre mesmo executando upgradeSteps na ordem especificada do link e também para a versão 1.5.3.
Para simular, crie um portal na versão 1.1.4, e nas configurações da capa, coloque como disponível o tipo "Enquete". Atualize para 1.5.2 ou 1.5.3, atualizando na ordem proposta em https://github.com/plonegovbr/portal.buildout/releases/tag/1.5.3: ocorre o erro descrito nesse relato.
O erro é similar ao que foi feito em plonegovbr/brasil.gov.tiles#250, mas teria de ser feito no collective.cover, no upgradeStep v14. Por isso fiz o comentário em plonegovbr/brasil.gov.tiles@399159f#r31123366. Mas não sei se é o mais correto pois esse erro não ocorreria se fosse só o collective.cover instalado.
Outra forma de evitar o erro é de, antes de atualizar, ir no painel de controle do collective.cover e clicar em "Salvar" antes de rodar os upgradeSteps (e lembrar de readicionar o tipo "enquete" novamente), ou rodar os upgradeSteps de brasil.gov.tiles (ver https://github.com/plonegovbr/brasil.gov.tiles/blob/1.x/src/brasil/gov/tiles/upgrades/v4004/__init__.py#L35) antes de rodar do collective.cover. Mas não sei se mudar essa ordem poderia causar outros impactos.
Na verdade foi outra coisa que me preocupou: antes de rodar o upgradeStep, o registro collective.cover.controlpanel.ICoverSettings.available_tiles continha:
[u'agenda', u'audio', u'audiogallery', u'collective.cover.banner', u'collective.cover.carousel', u'collective.cover.collection', u'collective.cover.list', u'collective.cover.richtext', u'em_destaque', u'mediacarousel', u'nitf', u'social', u'standaloneheader', u'video', u'videogallery', u'banner_rotativo', u'poll']Após rodar o upgradeStep, que falha lançando uma exceção, o registro passa a ser esse, com o collective.cover.calendar adicionado:
[u'agenda', u'audio', u'audiogallery', u'collective.cover.banner', u'collective.cover.carousel', u'collective.cover.collection', u'collective.cover.list', u'collective.cover.richtext', u'em_destaque', u'mediacarousel', u'nitf', u'social', u'standaloneheader', u'video', u'videogallery', u'banner_rotativo', u'poll', u'collective.cover.calendar']Ou seja, houve persistência no ZODB mesmo com falha no request, sendo que o esperado a meu ver era o rollback da transação.
Por isso que "rodar mais de uma vez" o upgradeStep funciona: o poll problemático continua no registro, mas como o collective.cover.calendar foi persistido, não entra mais no if do upgradeStep que dá o problema, e, rodando os upgradeSteps de brasil.gov.tiles, esse poll passa a ser collective.polls:
[u'agenda', u'audio', u'audiogallery', u'collective.cover.banner', u'collective.cover.carousel', u'collective.cover.collection', u'collective.cover.list', u'collective.cover.richtext', u'em_destaque', u'mediacarousel', u'nitf', u'social', u'standaloneheader', u'video', u'videogallery', u'banner_rotativo', u'collective.cover.calendar', u'collective.polls']@hvelarde você já viu erro parecido com esse do registry?
eu acho que isso tem que ser solucionado rodando o upgrade step que remove esse tile (plonegovbr/brasil.gov.tiles#215) antes de rodar os upgrades steps do collective.cover; isso ai complica um pouco a migração e tal vez precise ser feito algum ajuste para evitar o problema.
@hvelarde talvez seria melhor remover todas as titles que estão em available_tiles e não estão em registered_tiles, antes de adicionar a tile collective.cover.calendar em available_tiles.