This also happens for the following objects: 
pods: 

 PG::InvalidRowCountInResultOffsetClause: ERROR: OFFSET must not be negative : SELECT "container_groups"."id" AS t0_r0, "container_groups"."ems_ref" AS t0_r1, "container_groups"."name" AS t0_r2, "container_groups"."ems_created_on" AS t0_r3, "container_groups"."resource_version" AS t0_r4, "container_groups"."restart_policy" AS t0_r5, "container_groups"."dns_policy" AS t0_r6, "container_groups"."ems_id" AS t0_r7, "container_groups"."container_node_id" AS t0_r8, "container_groups"."last_perf_capture_on" AS t0_r9, "container_groups"."container_replicator_id" AS t0_r10, "container_groups"."ipaddress" AS t0_r11, "container_groups"."type" AS t0_r12, "container_groups"."container_project_id" AS t0_r13, "container_groups"."phase" AS t0_r14, "container_groups"."message" AS t0_r15, "container_groups"."reason" AS t0_r16, "container_groups"."container_build_pod_id" AS t0_r17, "container_groups"."created_on" AS t0_r18, "container_groups"."deleted_on" AS t0_r19, "container_groups"."old_ems_id" AS t0_r20, "container_groups"."old_container_project_id" AS t0_r21, "container_projects"."id" AS t1_r0, "container_projects"."ems_ref" AS t1_r1, "container_projects"."name" AS t1_r2, "container_projects"."ems_created_on" AS t1_r3, "container_projects"."resource_version" AS t1_r4, "container_projects"."display_name" AS t1_r5, "container_projects"."ems_id" AS t1_r6, "container_projects"."created_on" AS t1_r7, "container_projects"."deleted_on" AS t1_r8, "container_projects"."old_ems_id" AS t1_r9, "ext_management_systems"."id" AS t2_r0, "ext_management_systems"."name" AS t2_r1, "ext_management_systems"."created_on" AS t2_r2, "ext_management_systems"."updated_on" AS t2_r3, "ext_management_systems"."guid" AS t2_r4, "ext_management_systems"."zone_id" AS t2_r5, "ext_management_systems"."type" AS t2_r6, "ext_management_systems"."api_version" AS t2_r7, "ext_management_systems"."uid_ems" AS t2_r8, "ext_management_systems"."host_default_vnc_port_start" AS t2_r9, "ext_management_systems"."host_default_vnc_port_end" AS t2_r10, "ext_management_systems"."provider_region" AS t2_r11, "ext_management_systems"."last_refresh_error" AS t2_r12, "ext_management_systems"."last_refresh_date" AS t2_r13, "ext_management_systems"."provider_id" AS t2_r14, "ext_management_systems"."realm" AS t2_r15, "ext_management_systems"."tenant_id" AS t2_r16, "ext_management_systems"."project" AS t2_r17, "ext_management_systems"."parent_ems_id" AS t2_r18, "ext_management_systems"."subscription" AS t2_r19 FROM "container_groups" LEFT OUTER JOIN "container_projects" ON "container_projects"."id" = "container_groups"."container_project_id" LEFT OUTER JOIN "ext_management_systems" ON "ext_management_systems"."id" = "container_groups"."ems_id" WHERE (container_groups.deleted_on IS NULL) ORDER BY LOWER("container_groups"."name") ASC LIMIT $1 OFFSET $2 [container_group/show_list]

Replicators: 

 PG::InvalidRowCountInResultOffsetClause: ERROR: OFFSET must not be negative : SELECT "container_replicators"."id" AS t0_r0, "container_replicators"."ems_ref" AS t0_r1, "container_replicators"."name" AS t0_r2, "container_replicators"."ems_created_on" AS t0_r3, "container_replicators"."ems_id" AS t0_r4, "container_replicators"."resource_version" AS t0_r5, "container_replicators"."replicas" AS t0_r6, "container_replicators"."current_replicas" AS t0_r7, "container_replicators"."container_project_id" AS t0_r8, "container_replicators"."created_on" AS t0_r9, "container_projects"."id" AS t1_r0, "container_projects"."ems_ref" AS t1_r1, "container_projects"."name" AS t1_r2, "container_projects"."ems_created_on" AS t1_r3, "container_projects"."resource_version" AS t1_r4, "container_projects"."display_name" AS t1_r5, "container_projects"."ems_id" AS t1_r6, "container_projects"."created_on" AS t1_r7, "container_projects"."deleted_on" AS t1_r8, "container_projects"."old_ems_id" AS t1_r9, "ext_management_systems"."id" AS t2_r0, "ext_management_systems"."name" AS t2_r1, "ext_management_systems"."created_on" AS t2_r2, "ext_management_systems"."updated_on" AS t2_r3, "ext_management_systems"."guid" AS t2_r4, "ext_management_systems"."zone_id" AS t2_r5, "ext_management_systems"."type" AS t2_r6, "ext_management_systems"."api_version" AS t2_r7, "ext_management_systems"."uid_ems" AS t2_r8, "ext_management_systems"."host_default_vnc_port_start" AS t2_r9, "ext_management_systems"."host_default_vnc_port_end" AS t2_r10, "ext_management_systems"."provider_region" AS t2_r11, "ext_management_systems"."last_refresh_error" AS t2_r12, "ext_management_systems"."last_refresh_date" AS t2_r13, "ext_management_systems"."provider_id" AS t2_r14, "ext_management_systems"."realm" AS t2_r15, "ext_management_systems"."tenant_id" AS t2_r16, "ext_management_systems"."project" AS t2_r17, "ext_management_systems"."parent_ems_id" AS t2_r18, "ext_management_systems"."subscription" AS t2_r19 FROM "container_replicators" LEFT OUTER JOIN "container_projects" ON "container_projects"."id" = "container_replicators"."container_project_id" LEFT OUTER JOIN "ext_management_systems" ON "ext_management_systems"."id" = "container_replicators"."ems_id" ORDER BY LOWER("container_replicators"."name") ASC LIMIT $1 OFFSET $2 [container_replicator/show_list]


Services: 

 PG::InvalidRowCountInResultOffsetClause: ERROR: OFFSET must not be negative : SELECT "container_services"."id" AS t0_r0, "container_services"."ems_ref" AS t0_r1, "container_services"."name" AS t0_r2, "container_services"."ems_created_on" AS t0_r3, "container_services"."resource_version" AS t0_r4, "container_services"."session_affinity" AS t0_r5, "container_services"."portal_ip" AS t0_r6, "container_services"."ems_id" AS t0_r7, "container_services"."container_project_id" AS t0_r8, "container_services"."service_type" AS t0_r9, "container_services"."container_image_registry_id" AS t0_r10, "container_services"."created_on" AS t0_r11, "container_projects"."id" AS t1_r0, "container_projects"."ems_ref" AS t1_r1, "container_projects"."name" AS t1_r2, "container_projects"."ems_created_on" AS t1_r3, "container_projects"."resource_version" AS t1_r4, "container_projects"."display_name" AS t1_r5, "container_projects"."ems_id" AS t1_r6, "container_projects"."created_on" AS t1_r7, "container_projects"."deleted_on" AS t1_r8, "container_projects"."old_ems_id" AS t1_r9, "ext_management_systems"."id" AS t2_r0, "ext_management_systems"."name" AS t2_r1, "ext_management_systems"."created_on" AS t2_r2, "ext_management_systems"."updated_on" AS t2_r3, "ext_management_systems"."guid" AS t2_r4, "ext_management_systems"."zone_id" AS t2_r5, "ext_management_systems"."type" AS t2_r6, "ext_management_systems"."api_version" AS t2_r7, "ext_management_systems"."uid_ems" AS t2_r8, "ext_management_systems"."host_default_vnc_port_start" AS t2_r9, "ext_management_systems"."host_default_vnc_port_end" AS t2_r10, "ext_management_systems"."provider_region" AS t2_r11, "ext_management_systems"."last_refresh_error" AS t2_r12, "ext_management_systems"."last_refresh_date" AS t2_r13, "ext_management_systems"."provider_id" AS t2_r14, "ext_management_systems"."realm" AS t2_r15, "ext_management_systems"."tenant_id" AS t2_r16, "ext_management_systems"."project" AS t2_r17, "ext_management_systems"."parent_ems_id" AS t2_r18, "ext_management_systems"."subscription" AS t2_r19 FROM "container_services" LEFT OUTER JOIN "container_projects" ON "container_projects"."id" = "container_services"."container_project_id" LEFT OUTER JOIN "ext_management_systems" ON "ext_management_systems"."id" = "container_services"."ems_id" ORDER BY LOWER("container_services"."name") ASC LIMIT $1 OFFSET $2 [container_service/show_list]

I don't fully understand the scenario or what is the simlink here (is it a breadcrumb or a link in a relationship section?).
any any case, the exception described doesn't seem related to topology.

It's the breadcrumb link

Federico, please see the exception here, I find it hard to tie it to topology.

(In reply to Alissa from comment #4)
> Federico, please see the exception here, I find it hard to tie it to
> topology.

Not related to the topology.

WRT how to solve this: I don't think we should try to fix the "Container Node" link crash; we should instead concentrate on showing the correct link back to Topology.

imo this bug has no relation to topology.
I followed the scenario described:
1. in topology, user selected a container node and pressed "go to summary page".
2. the user was correctly navigated to that node's summary page.
3. the breadcrumb is showing "container nodes --> that specific container node name". this is the expected behavior, topology should not show there and is indeed not part of the breadcrumbs.
4. pressing on the link to "container nodes" in the breadcrumb seems to produce an exception.
there is no link nor breadcrumb back to topology from entities, and it should not be there either. (unless there's an RFE about it instead of entity based topology)
imo the bug is about making breadcrumbs for nodes to work correctly.

The url in these occurrences contains 'page='
i.e. http://localhost:3000/container_node/show_list?page=&refresh=y

this PR assigns a default page=1 
https://github.com/ManageIQ/manageiq/pull/8925

For every entry in the Tab the breadcrumbs behavior is the same: you start from one and then you move around through relationships that are maintained in the history. E.g.:

 Containers Providers  >>  Neutrino (All Projects)  >>  default (Summary)
 Projects  >>  openshift-infra (Summary)  >>  Neutrino (Summary)
 Routes  >>  hawkular-metrics (Summary)  >>  openshift-infra (Summary)
 Container Services  >>  hawkular-cassandra (Summary)  >>  openshift-infra (Summary)
 Replicators  >>  frontend-1 (Summary)  >>  test (Summary)
 Pods  >>  frontend-1-8v0w6 (Summary)  >>  test (Summary)
 Containers  >>  openshift-infra (Summary)  >>  hawkular-cassandra-1-l09eo (Summary)
 Container Nodes  >>  oshift01.eng.lab.tlv.redhat.com (All Pods)  >>  Molecule (Summary)
 Persistent Volumes  >>  metrics-volume-01 (Summary)  >>  Neutrino (Summary)
 Container Builds  >>  ruby-hello-world (Summary)  >>  hello-world (Summary)
 Image Registries  >>  docker.io (All Images)  >>  fedora (Summary)
 Images  >>  test/origin-ruby-sample (All Projects)  >>  test (Summary)

Any reason for the Topology to behave differently?

Isn't the user going to be confused by the fact that for all other entries the breadcrumbs actually represent the navigation history but for Topology (and Overview?) they don't?

For example, as reported in this BZ, when you land on a node page you'll find a "Container Nodes" page in the breadcrumbs history that you never visited before, because indeed you are coming from the Topology page instead?

this is representing more hierarchy and relationship between entities then browsing history. when you see containers->containerA->images->imageB, then there is some relationship between them. 
If you try for example to move from a container image to a vm, breadcrumbs won't be displayed as you have to go through a main menu and they have no relationship.
Topology and dashboard are representation pages for the "state of the inventory", and iirc this was the behavior for breadcrumbs (or lack of it) that was set for them.
If this needs to be revisited (for all topologies and dashboards in all providers), it should be an RFE and discussed with PM and UXD.

Alissa, do other pre-existing dashboards\view behave this way?
(Im having a hard time finding out without a non-containers env)

(In reply to Alissa from comment #10)
> this is representing more hierarchy and relationship between entities then
> browsing history.

If you look closely at the examples above the hierarchy is not always involved, it's more a navigation history through relationships.

In fact a more evident example would be:

 Container Nodes >> oshift02.eng.lab.tlv.redhat.com (Summary) >> hawkular-metrics (All Pods) >> hawkular-metrics-kwufy (Summary) >> Molecule (All Projects) >> demo5 (Summary)

> If you try for example to move from a container image to a vm, breadcrumbs won't be displayed as you have to go through a main menu and they have no relationship.

I am not sure I can follow this. From a container image I navigate to the relevant nodes, and I select one and breadcrumbs are correct:

 Images >> openshift/mysql-55-centos7 (All Nodes) >> vm-48-9.eng.lab.tlv.redhat.com (Summary)

but then when I follow the underlying vm relationship I land in an explorer that has no breadcrumbs at all.

On the other hand if you're saying that from the container image you travel directly to VMs... then yes, using the main menu always resets the breadcrumbs.

> Topology and dashboard are representation pages for the "state of the
> inventory", and iirc this was the behavior for breadcrumbs (or lack of it)
> that was set for them.
> If this needs to be revisited (for all topologies and dashboards in all
> providers), it should be an RFE and discussed with PM and UXD.

It seems that that approach has led us to several special cases that are confusing, (in addition and on the contrary to what we discussed above) for example: Topology is in the breadcrumbs when you reach it from the provider page:

 Containers Providers >> Neutrino (All Nodes) >> Topology

but then it get reset when you pick one of the items, e.g. in case of a node:

 Container Nodes >> vm-48-8.eng.lab.tlv.redhat.com (Summary)

There should be a clear unified approach towards breadcrumbs in the product, and then everyone can follow it. Currently some navigation clears breadcrumbs, some doesn't, explorer has no breadcrumbs at all, etc.
I believe this is a matter for UI and UX teams to decide for all the product, and then specific parts that require adjustment should be fixed.

Some points that I have in mind for the approach:

1. how "long" should the navigation history be? if user now "travelled" through 20 screens, breadcrumbs would be kept and displayed for 20 screens, taking several rows and a lot of screen space will be dedicated just for that?
at which points/situations should this be cleared?

2. what is the benefit for the user of displaying navigation history in the first place? does it exist in other products? (rhev, openshift, hawkular, etc)

3. why explorer should be different than other screens if breadcrumbs is for navigation and not hierarchy?

Regardless of the discussion above, a PR with a fix for the error described has been merged.
The default page number would now be correctly set.

Still happens on build 5.6.0.9-rc2.20160531154046_b4e2f6d

Unexpected error encountered

Errors in Management Engine can be caused by:

① Accessing Management Engine from multiple tabs or windows of the same browser on a single machine. Close any duplicate browser sessions, then select a menu option above.
② Pressing the back button during a session. 
      Close any duplicate browser sessions, then select a menu option above.
③ An internal system error. 
      Please contact your administrator for assistance.


Error text:

PG::InvalidRowCountInResultOffsetClause: ERROR: OFFSET must not be negative : SELECT "container_nodes"."id" AS t0_r0, "container_nodes"."ems_ref" AS t0_r1, "container_nodes"."name" AS t0_r2, "container_nodes"."ems_created_on" AS t0_r3, "container_nodes"."resource_version" AS t0_r4, "container_nodes"."ems_id" AS t0_r5, "container_nodes"."lives_on_type" AS t0_r6, "container_nodes"."lives_on_id" AS t0_r7, "container_nodes"."last_perf_capture_on" AS t0_r8, "container_nodes"."identity_infra" AS t0_r9, "container_nodes"."identity_machine" AS t0_r10, "container_nodes"."identity_system" AS t0_r11, "container_nodes"."type" AS t0_r12, "container_nodes"."kubernetes_kubelet_version" AS t0_r13, "container_nodes"."kubernetes_proxy_version" AS t0_r14, "container_nodes"."container_runtime_version" AS t0_r15, "container_nodes"."max_container_groups" AS t0_r16, "container_nodes"."created_on" AS t0_r17, "ext_management_systems"."id" AS t1_r0, "ext_management_systems"."name" AS t1_r1, "ext_management_systems"."created_on" AS t1_r2, "ext_management_systems"."updated_on" AS t1_r3, "ext_management_systems"."guid" AS t1_r4, "ext_management_systems"."zone_id" AS t1_r5, "ext_management_systems"."type" AS t1_r6, "ext_management_systems"."api_version" AS t1_r7, "ext_management_systems"."uid_ems" AS t1_r8, "ext_management_systems"."host_default_vnc_port_start" AS t1_r9, "ext_management_systems"."host_default_vnc_port_end" AS t1_r10, "ext_management_systems"."provider_region" AS t1_r11, "ext_management_systems"."last_refresh_error" AS t1_r12, "ext_management_systems"."last_refresh_date" AS t1_r13, "ext_management_systems"."provider_id" AS t1_r14, "ext_management_systems"."realm" AS t1_r15, "ext_management_systems"."tenant_id" AS t1_r16, "ext_management_systems"."project" AS t1_r17, "ext_management_systems"."parent_ems_id" AS t1_r18, "ext_management_systems"."subscription" AS t1_r19 FROM "container_nodes" LEFT OUTER JOIN "ext_management_systems" ON "ext_management_systems"."id" = "container_nodes"."ems_id" ORDER BY LOWER("container_nodes"."name") ASC LIMIT $1 OFFSET $2 [container_node/show_list]

This should no longer happen I think the build you were working with didnt include the fix. 
Could you recheck on a newer build and include the browser location here if this happens again?

Fixed on 5.6.0.10-rc2.1.20160607103248_d06c141

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2016:1348